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..
Hetz
It's not clear that the LSB will force RedHat to change their directory structure. In fact, it might be so general as to not change a thing.
Also, related to RedHat:
what do you do when some of the rpm's are missing?
For RedHat 6.2:
The latest stable branch is missing a kde-graphics rpm file.
The BetaR2 version is missing kde-networks.
In this case, I think the Installer will be a beautiful way of telling you that you're hosed.
It's not clear that the LSB will force RedHat to change their directory structure. In fact, it might be so general as to not change a thing.
It might, if Linus Torvalds would support the LSB in such as way that he would deny any distribution not adhering to it to use the Linux trademark.
RedHat is the only one to put KDE in the right place. Though it would be better if there was a /etc/kde
/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.
I believe that the previous comment wa ment to be funny...
No, it proposed using /etc/kde for the *rc files, instead of /usr/share/config.
/etc is still not the place for KDE rc files. /etc is for system files. It should be under
the KDE home directory, as with other /opt softwares are.
jason
Hmm .. what about for example /etc/smb.conf and /etc/postfix/* .. strictly speaking they are applications, even though they provide services and don't actually have "user facing" interfaces.
And I notice there is already an /etc/gnome/*
Macka
KDe already has configuration files in KDEDIR/share/config and HOME/.kde/share/config. Nothing goes in /etc.
Seems unlikely, Linus has made a point of not supporting or dissing any distribution.
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.
You obviously have never head of BSD before ;)
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).
Yeah. Just use KDE with Debian, and you don't need anything else: kde.debian.net is enough ! I know that KDE developpers must hate the Debian community, but happily war is over now :)
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.
Come on Mandrake will have it with 8.0 I'm sure.
Craig
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?
SD
Avec :
rpm --excludepath
peut-être ???
With :
rpm --excludepath
Perhaps
Sorry I have forgotten that I was on a English site :))
Yeah, thats something i d like to have as well. A grapical
exclude to progs in one rpm i dont need.
Well, do it the Debian way, or the way Mandrake is going now, by splitting the packages into individual components :) Like, one for each game, for example.
Regards,
Michel
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?
Regards, Stefan.
Yes !!!
And call it kpackage :)
In France, we have an expression for this :
"Ré-inventer la roue"
(Invent the wheel again)
Sorry, kpackage is taken. It's the package manager for kde. However...how about simply kinstaller? or...kdenow? or gokde?
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)
Just a suggestion...
<< Sorry, kpackage is taken. It's the package manager for kde. However...how about simply kinstaller? or...kdenow? or gokde? >>
It was a joke (ironic) : I know kpackage and I just wanted to say that the idea of Stephan already exists and her name was kpackage.
lol Now thats funny.
Craig
Has SD said :
It will be better if the user can select each application he wants to install.
kteatime is the only application I use in kdetoys for example.
A GUI to install KDE is usefull but if there are no other features, it will be more easy to use :
"rpm -i *.rpm " in the kde_directory_of_your_distrib
For the first time Installation the Wizard approach is nice. But when you want to update or install additional software it's not the best idea.
Have you ever tryed out the Ximian (formerly Helix) Installer?
It lists Software in some categories:
* Messages (just some information)
* Importent Updates (Security issues & stuff)
* Updates
* New Software Packages
They are also working on a new installer. Which can handle so called "Channles", which you can offer your software.
It would be good if you could do following things:
* Manage multiple rpm/dep repositories (sources)
* Use apt for rpm+dep
* View packages in the manner described above
* Show packages to install ordered by sources
* Show those packages by category
...
Maybe the updater part should base on the kpackage tool which offers some of the required features yet. But lacks a moderated channel view of packages possible to install.
So it would be a powerful tool not only for installing kde packages.
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.
I think that's pretty damn sweet!
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?
That's a great idea, really slick!
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.
That brought a tear to my eye. Why can't wejust get along? lol
Craig
That brought a tear to my eye. Why can't wejust get along? lol
Craig
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.
No! It would NOT be nice. It would be nice if Red-Carped could do the job. (And it actually can) Why would KDE need to have a installer that does _exactly_ the same like an already existing one?
Yes please, can we have a KDE installer which fucks up your system too. Really, I think this KDE vs Gnome feature-for-feature war is going to far.
When can we have a red-carpet type of installer so that I dont have to download every single RPMs everytime when I want to upgrade something KDE?
Red-Carpet will allow you to upgrade your KDE software as well, I asked them at LWE ;-)
What's cool about it is that they didn't make it GNOME-centric, they have a totally separate backend so maybe you guys could write a KDE front-end to their backend?
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: |
|
- stable
|
-kmail-1.9.99.tar.gz
-ark-1.2.3.tar.gz
-konsole-1.0.1.tar.gz
-kuser-1.9.8.tar.gz
-....
-....
-....
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.
Regards,
David.
hi,
just two things to notice:
a. loki has done an open sourced installer etc for their games
b. i think, ibs is working for in installer too.
maybe it could help to look at these too.
-gunnar