Good points hetz...but I think the issues surrounding the political
issues of red carpet are non only political.

I think lots of people want to see it fill into the desktop in terms of
visual and technological issues. We would possibly want to use DCOP, and
we certainly want it to be part of the KDE style the user is using.

It may be an idea that Red Carpet is hacked towards a KDE/Qt version but
I don't know. I just look forward to seeing what is created as a result
of this thread.

Who is actively going to work on this installer?

	Jono

-----Original Message-----
From: Hetz Ben Hamo [mailto:hetz@kde.org]
Sent: 21 August 2001 12:01
To: kde-devel@kde.org; Jonathan Bacon
Cc: kde-core-devel@kde.org
Subject: Re: starting to write a KDE auto-installer


Hi Jonathan, others...

I look at the installer and I think I'm finding myself in an un-usual=20
position - and I'll explain...

I have talked with Ilya yesterday and we both found out that actually=20
Ximian's Red-Carpet is capable of doing the install job with some
advantages=20
over other installer/updaters, and I will specify:

* it can handle both RPMS and DEBs
* it can handle mirrors very nicely
* it's small - 3 MB
* it doesn't require any external lib (it's staticly linked)
* It has proxy support
* it can be expanded for additional "channels" (think of a channel like=20
apps.kde.com) so it can be used after the installation of KDE.
* the dependencies are written in a simple XML file
* and most important - it has been tested by millions, and the
technology=20
behind it is proven to work.
* no need a special purpose server for the installation - the installer
just=20
need to grab 1 small text file (a list of mirrors) and proceed the=20
installation from the mirror.

The biggest disadvantage of Red Carpet (at least in #kde channel on IRC)
is=20
that its using the "competing" desktop's technology. I personally have
no=20
problem to use it - as we say "use the right tool for the right job" and
IMHO=20
- it is the right tool, so the disadvantage is more "political" then=20
technical (which makes me wonder - we use libXML from gnome and no one
seems=20
to have problem with it) - so it's up to the core-devel team to decide
wether=20
to embrace it or not...

Now - anyone can take this Red Carpet and port it to QT, however it's a
big=20
job to replace gtk, gtk-html (which ironicly came from kde), gnet and if
I'm=20
not mistaken - SOUP - but I doubt that after the port - the static
binary=20
will be as small as 3 MB.

In terms of packaging - the packager will only need to write a simple
XML=20
file which describe the dependencies and add those RPMs/DEBs and add it
to=20
the file lists with the RPMs.

In order to use it today - it needed to be slightly modified to grab the

mirrors list and XML files from another location and not Ximian servers,
and=20
to change the graphics..

So the question remains - if the KDE team will adopt red-carpet as an
offical=20
X86 installers (I doubt other platforms needs it since they got an=20
established packaging mechanism and the last thing they need is an
installer=20
- like Sun or SGI).

I have checked the alternatives - and here is my conclusion..

* Yast/Yast2 (SuSE), URPMI (mandrake), up2date (Redhat) - they're all
like a=20
first generation updaters/installers - some of them for example don't
have=20
proxy support, some gives me a nice message ("you're system is updated -
even=20
that it didn't get KDE 2.2") and others simply don't have KDE 2.2 in
their=20
update database..

* Kinstaller - it looks very nice, but it's still in development (65% if
I'm=20
not mistaken) and it needs to be finalized and to be tested. It also
doesn't=20
have many features that I mentioned above.

So these are the options - it's all up in the air and needed to be
decided..

Opinions?

--=20
Hetz Ben Hamo
hetz@kde.org
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<