There have been countless requests from KDE users, on the dot, on the lists, and even elsewhere, for a KDE Installer and Updater. Nick Betcher (aka Error403) has stepped up to the challenge and now needs your help to make this project really happen. His current code is in CVS and the project is in active development. The install starts off with an intro/detection screen, prompts the user for the type of installation, prompts for the destination of the KDE installation, and then prompts for the packages to install (see all the screenshots here). The project is based on pure Qt, so that the statically linked binary will be small, and as of now the network code to download RPMs is in CVS. So why does Nick need your help? It's important to him that users get their input in for this project and that he has a better understanding of what to aim for regarding look & feel as well as packaging issues. He also needs other developers to get involved, as he is relatively new to C++/OO programming. Nick has provided a convenient forum for people to voice their opinion.

Comments

This is the way to go, Nick! The screenshots show really what people want to have. I don't understand really why you need help. Once people select what packages they want to install, it is just a matter of executing few "rpm -i" commands.
Another question: this installer seems to propose /opt/kde2 directory, where kde2 should be installed. My current 2.1beta distribution is installed in /usr.
Why this mess? Wouldn't be easier to agree on where kde2 should be installed by default, then if someone really wants to have it somewhere else, installer would allow him to do that?

Go ahead, try to convince Redhat to install KDE on any other place other then /usr - the issue has already been arisen and Redhat has an internal (very thick) book which describe what will be installed and where to be installed..

Lets hope that one the LSB (Linux Standard Base) will be finally out as version 1.0 - then all of the distributions will be on the same place..

/etc should only be used for (system-wide) configuration files. The best place for KDE is really /opt/kde. Even though /opt is hardly used, it is a recognized and preferred installation path for many years.

Apart from Red Hat 7.0, that is. Linus called it "totally broken" for use as a development platform, referring to the broken gcc snapshot they shipped with 7.0. They later fixed the error, but he was right to speak out. RH are getting a bit, um, complacent.

Gah! Repeat after me: KDE is not a linux distribution. Let the distributions do this; it's their job. Distributions ought to have a single tool for adding and removing software. And I mean adding software that you haven't downloaded yet. Feeding a previously d/led rpm to a package manager doesnt cut it. It ought to act like a catalog of software that you can pick stuff you want and it'll D/L the RPMs and handle dependencies. Debian does this, but not in a newbie-friendly way.

Dittos! If this project were an update manager instead, or a "so you don't forget a step" automatic build script, it might make a bit more sense, but...

An installer needs to be a binary to be of any practical use (or what's the point?). So how does it work on FreeBSD? And will it then proceed to install Linux binaries to FreeBSD? Or what about Slackware? Will this install the Redhat-centric kde-admin to Slackware?

Ximian screwed *BSD, Slackware and Stampede without even the courtesy of a reach-around, so I hope this project isn't as cavalier...

People actually use Stampede still? I used to be a developer for Stampede so I can say that.

I've heard that Ximian will support the BSD systems as their next platforms. I dunno about Slackware though (but then again, does Slackware even have dependency checking? No. But the *BSDs do apparently.)

Ximian really didn't ``screw'' BSD, slack, or stampede, 'cause A) I believe that they roll the changes they make back into the standard gnome project, and B) It's easy enough to compile Helix gnome with the patches on a non redhat/sun/debian system (I'm using it on a linuxfromscratch system) so if one wanted to he could make a BSD port, or slack/stampede package with the only thing missing being the auto updater.
Of course, this is only a short term solution, with the long term solution being to create a standard package management system that would be common for UNIX systems (similar to the way that the GNU autotools are cross platform).

Just started using Stormix after having used SuSE, Red Hat and Mandrake. Stormix has a nice GUI frontend to apt which makes it even easier to use. Apt is great. As has been pointed out, no other dist would be interested in providing this kind of update service...

Also worth noting: Stormix has gone belly up but stormpkg lives on in the current unstable package tree. It really is the best apt front end I have used.

Also worth noting: Eazel Nautilas, October GNOME, and KDE 2.1beta2 are all available from the main Debian unstable tree. Ximian GNOME is available from Ximian's FTP servers and KDE2 for Debian stable is available from kde.tdyc.com.

So you won't use it. It makes things easier for a lot of people whose distributions (or custom systems) didn't include KDE. Nobody is forcing you to use it, so don't complain about it. I'm glad something like this is finally being done, it helps out the newbie. The real question is will it still work on other kernels besides Linux?

Thanks Nick, this will help the KDE project alot.
The one suggestion I have is the user should also be able to select individual applications within the packages for installation. I have no idea if this is even possible when installing from RPMs. Anyone know if this can be done?

Hm. It's very nice to have a KDE installer and I think it may help a lot of people although the Linux distribution's interface/installer should take care about most of this anyway. As for me I always install KDE from the sources :-)...

However, I think it is even more important for KDE to have a nice application installer that looks like this nice KDE installer.

Okay, many people might now say: "Hey, what do we need this for when we have a nice RPM installer?" but I believe that this argument doesn't count.

What I think is required is something that looks and works exactly like this nice KDE installer presented here but does not (only) (de-)install KDE itself but also applications, not necessarily limited to KDE apps. What do you think?

Still...I was wondering...isn't it simpler to use cvsup? Track the STABLE branch and you should be okay...perhaps some kind of kde-front end? (which would customize the make, install scripts for the user - the user can select which he/she wants to download and install)

Their new Red-Carpet program (the next generation of Helix-Update) can handle more than just GNOME packages now. It will supposedly even be able to install KDE packages as well as update my SuSE system, etc.

apps.kde.com has a large number of KDE packages. If apps.kde.com could provide an XML file or description file of the KDE packages available on that server (including download links, package format, version, conflict information, dependencies), maybe your program could use this to provide up to date install options to the user?

I have to add here, that RedHat already created such a framework which is used by GnoRPM it uses a RDF files (I think). But in my opinion GnoRPM isn't a much usefull tool. On the other side Debian has index-files used to find out required packages (resolve dependencies). And Ximian has their own XML stuff.

Maybe it's the best to adapt Red-Carpet and build a KDE frontend (see posting of an "Anonymous Coward" below) - and maybe extend its functionality. I didn't want to talk about such stuff: But we shouldn't see Gnome or Gnome centric companies as KDE's enemies, but see it as oppurtunity for making things better and learn from each other. Amen.

I think Uwe's nailed it. It really seems to me that
what a lot of people are looking for is something
very similar to Ximian's updater/installer, where
you have choices of which mirror to use,
categories of packages, etc.

Yea, Ximian's installer is pretty nice. Have you seen Red-Carpet? I checked out their booth at LWE and saw a demo of Red-Carpet and I practically fell in love! I would install Ximian GNOME just to have Red-Carpet! It would be so nice if KDE had something exactly like it.

Exactly. If the Ximian team is creating this to update KDE packages as well, this would be an excellent project for KDE and Gnome developers to cooperate on and produce something consistent on the Linux/UNIX platform. Everyone wins.

Time for another long post, this is part of a mail I sent to a KDE developer back in early December last year on how I would like to code an Installer when I get time. At this time I had no time due to studying for exams which I still am but they end soon. I hope it covers some good ground and gives the author some new ideas / problems to think about. It's more complicated than just writting a download program for RPMS however and is mainly concerned with compiling from source as that's what I was interested in at the time as infact it's simplier due to different dependancies, libcs etc. Let me try and handle one issue though, people say this is something the distributions should do and I do agree with this except for the fact they are not doing it. Debian is an expection here and my hat is off to them but Debian is non profit and non profit means they have nothing to lose. The other distros rarely issue package updates except for security problems, if you could just buy Mandrake 6 two years ago and then automatically update it, why would anyone buy Mandrake 6.1, 6.2 etc. So, the distro's aren't exactly going to be falling over themselves to provide this feature if it costs them money. Ximian on the other hand.....Ah, just read my earlier post about their installer... So this covers some of the things I thought of for a way to get the KDE packaging sorted out and provide the basis of an installer. Binary distribution presents on big problem, packing the apps for each indivdual architecture that KDE supports and each sperate distribution for each arcitechture... It's got to be platform indpendant so where the orginal mail gos off to binaries and RPMs, I don't think RPM is a good idea as it's redhat derivitive distros only and hence is not on all systems. The best way to go would be to have a KDE apps DB local as mentioned first. It's also a lot bigger project than it first seems if it is to be done well.

***
On to packaging, I'd like your ideas on this: One of the "problems" I can see with KDE is its packaging. The packages are too large and although they cover a specific area i.e. networking, admin etc I don't want to install all the bits of each package. For example say I wanted to manage my ftpserver via a nice gui, I then also install a user manager, a cron job manager a dat drive tool etc. Say I want an email client (kmail) as most people do, I also get an archcie client, a news reader, a PPP daemon config util, a AOL instant messenger etc etc...

Most users install KDE from distributions and this is
exactly what they see, a heap of apllications that they don't need and for the most part don't even understand.

I think Linux has too many applications (well, to many similar apps anyway) and too many options. Bizare as it might seem this holds it back from the average user. I'd say with the current satus of Linux mainly power users and techies use it, these users are the kind that only want to install what they
need. Of course this also can be blamed on the distribution makers but we need to make it easier for them as well, the current way KDE make releases isn't that effective.

Solution:

1. KDE core should be maintained as it currently is the 3 main packages:
kdesupport
kdelibs
kdebase

IMHO I think kdesuppport should be phased out if possible but this will take time? Possible solution to getting rid of kdesupport would lie with the distribution makers. I *think* KDE currently needs mimelib and libaudio from kdesupport on my system even though it contains other packages, these aren't
compiled by default as I guess I already have them. Surely we can just make these few libs a dependancy for KDE base?
Look at it this way, we need openssl for crypto support in konqy, this is an important feature, why's it not in kdesupport? What about Lesstif for netscape plug ins or a java implimentation? Of course mimelib and libaudio are version critical to the correct operation of core fuctionality of KDE where as the other libs mentioned above provide "nice to have" functionality.
Even so, I can see this only from two sides, which are:

A) Techie compiling KDE from source. If he/she has the knowledge to compile KDE from source they should have the knowledge to get the dependant packages. If he/she doesn't have the ability to read figure out why configure complained about a missing package and read the README what are they doing compiling KDE themselves.

B) Average Linux dude that installs from a distribution. The distribution just has to package KDE correctly with the correct libs as a dependancy on the KDE RPMs / APTS / slackwware packages. This can't be that hard, the distro people should get this right (I'd hope or else their in the wrong game), apart from that David Faure / Mosfet are at mandrakesoft, Bero is at
redhat, surely there are employees of the other major distros involved in the core team that could advise their colleauges.

2. Seperate all the apps out of their current groups so that for example kdenetwork, utils, multimedia etc are no more. A solution to this would be to sort CVS out in to two groups:

A) released: These are apps that are currently maintained, are actively developed and considered up to a high level. Basically 99% of the apps that now make up the various parts if the distribution. New work is commited in to HEAD as it is currently and releases are taged when the author(s) feels the
app has new fuctionality or a large bug sqashed. Of course releases should be compatable with the current stable core release. When a new release is made the tag should be packaged, for now this is a source only package in tar.gz
format (bare with me, works with the installer..). It must contain a file called KDE_RELEASE, this file has a strict layout or is in XML and contains at least all of the following information:

name
description
version
changes
importance

Once the tag has been placed and the KDE_RELEASE file added a script can be run against CVS to automatically package it, copy it to the KDE FTP site and remove the old version, it then gets mirrored from the KDE main site. The ftp site would be layed out the same way CVS is:
ftp.kde.org: |
|

Once every hour a script can be run on the ftp server to extract the KDE_RELEASE file from any new packages if they exist (based on time created I guess). This would update a file called KDE_RELEASES that lives in the root of stable, obviously this file contains up to date information on all released packages.

In it's self this is a far better way to release KDE for the power users out there who want a stable release but can compile what they need from source and I'm sure it will help the distros to package KDE better. This is not the end goal, the installer is.

The Installer: The installer is a simple gui app that acts with two functions, firstly it can install KDE once the base packages are in place and secondly it can keep KDE up to date. In the KDE root directory on the local machine lives a file called KDE_INSTALLED, this is a DB (XML / plain text) of
all packages installed on the machine and is created when kdebase is installed. Its updated by the "make install" script when a package is installed or as a post install script from RPM /apt etc. When the installer is run, it loads the KDE_INSTALLED file and asks where it should check for
new packages, either locally or the Internet. Locally brings up a location selector, so that for example magazine CDROM can contain packaged updates (a lot of people are still on dial up) or to install 3rd party software (something not released by KDE e.g. kcpuload). The Internet option connects to the ftp.kde.org and downloads a list of current mirrors, the user selects
a mirror and the KDE_RELEASES file is download. The installer compares this with KDE_INSTALLED and shows updates to installed packages + info such as importance, description etc. If the user wants to install a selected package
they select download & install, the installer then gets the package and performs a configure, make, make install. This exact commands should be configurable so that --enable-final, install-strip or lib paths could be could be configured for example.

As for installing KDE, the installer should have two radio buttons one for update that works as described above and only checks for installed packages and the second lists all packages where multiple packages can be selected and installed. Further options are for the installer to live in the system tray and check at regular intervals for updates from their favourite mirror, when an update is availible for an installed package it alerts the user.

The future: I think up to now, this gives KDE a solid base to expand this idea, sorts out CVS and it certainly lets the users decide what they want to install instead of the ever growing kdenetwork, kdeadmin etc packages. It helps the distributions and is atleast platform independant. The big problem
with this is that packages need to be compiled on the users machine so its not perfect for everyone especially joe average. However, if the installer does some checks on the development enviroment first it would satify a lot of KDE users out there as I'm sure most have compilers installed?. The other flaw is that it doesn't allow uninstalls to be performed which is I think an
important feature, this could be handled by having the KDE_INSTALLED DB keeping a list of files that "make install" installed and having the app update the DB if it updates a global config or adds files. This is not really an elegant solution and duplicates functions of other software (RPM
/APT)

I haven't tought the next bit through 100% but the idea is to have the first generation installer to get the source as above but to build RPMs and install them using KDE's own branch under the RPM DB. This way the packages are able to uninstall via RPM, this can be expanded later to use the installer to
check for updates to bin packages but bin packages create a new set of problems like install paths etc. I personally like RPM but some distros don't so there are politcal issues I guess, I do remember some distro writting an apt to RPM layer so that any packages could be used

B) going back to the CVS stuff, keep the nonbeta part of CVS, might be better to call it unreleased and move it to its own branch (if it's not already). Once a package in unreleased proves it stuff it can be moved to released and a first release can be made. Because everything would be a seperate package
it means that moving a package from nonbeta doesn't have to bloat up a package group as is the current situation.

I think the installer app should be fairly easy to do and I hope there is someone with the time to impliment it but getting CVS in the shape where this will work might be a little hard?

Anyway, the stuff above is just a few ideas that I can see from the outside, there may be very many reasons why this can't be done, but as I'm not that involved with KDE, I of course don't know about them. If this is some use, please feel free to forward it to the kde developers / mailing lists.