AW: starting to write a KDE auto-installer
Tue Aug 21 07:02:00 GMT 2001
> -----UrsprÃÂ¼ngliche Nachricht-----
> Von: firstname.lastname@example.org
> [ mailto:email@example.com]Im Auftrag von Hetz Ben Hamo
> Gesendet am: Dienstag, 21. August 2001 13:01
> An: firstname.lastname@example.org; Jonathan Bacon
> Cc: email@example.com
> Betreff: 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..
Please note, that the cygwin team ( http://www.cygwin.com ) which distributes a
posix emulation emulation layer for windows with many unix apps including xfree
and kde is going to use an new installer with rpm/dependency and pre/post
scripting possibilites. They are thinking about using a type of rpm installer
and as I know, they will integrate the mirroring and proxy functionality into.
Currently they are using a nativ windows setup tool with mirror and proxy
Initiation of this is caused by big cygwin packages, like xfree, kde for cygwin
and other graphical gui port, which needs some dependency checking of basic
libs and post installation and/pre deinstalling tasks.
On the cygwin side there are several concepts:
One guy has published a proof of concept under
One thread talks about an installer for cygwin/xfree
What about coming together and thinking about one tool for this all ?
I think this could be a unique chance to build something important and to
use resources effiently, because many preparing works is already done by many
people (I think about rpm, cygwin installer with mirroring and proxy support
and other) and many people would contribute many ideas
and programming and testing and so on.
Additional this could be a chance to bring together the unix and the window
KDE on cygwin http://kde-cygwin-sourceforge.net
More information about the Cygwin-apps