[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    RE: starting to write a KDE auto-installer
From:       "Jonathan Bacon" <j.bacon () delta ! wlv ! ac ! uk>
Date:       2001-08-21 11:09:23
[Download RAW message or body]

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 
position - and I'll explain...

I have talked with Ilya yesterday and we both found out that actually 
Ximian's Red-Carpet is capable of doing the install job with some
advantages 
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 
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 
behind it is proven to work.
* no need a special purpose server for the installation - the installer
just 
need to grab 1 small text file (a list of mirrors) and proceed the 
installation from the mirror.

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

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

In terms of packaging - the packager will only need to write a simple
XML 
file which describe the dependencies and add those RPMs/DEBs and add it
to 
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 
to change the graphics..

So the question remains - if the KDE team will adopt red-carpet as an
offical 
X86 installers (I doubt other platforms needs it since they got an 
established packaging mechanism and the last thing they need is an
installer 
- 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 
first generation updaters/installers - some of them for example don't
have 
proxy support, some gives me a nice message ("you're system is updated -
even 
that it didn't get KDE 2.2") and others simply don't have KDE 2.2 in
their 
update database..

* Kinstaller - it looks very nice, but it's still in development (65% if
I'm 
not mistaken) and it needs to be finalized and to be tested. It also
doesn't 
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?

-- 
Hetz Ben Hamo
hetz@kde.org

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[prev in list] [next in list] [prev in thread] [next in thread]