faq
flatforty
contribute
subscribe
configure
search
rdf
main
|
| KDE Package Policy Explained |
 Posted by Kurt Granroth on Tuesday 10/Apr/2001, @13:17
from the now-you-know dept.
It's clear that the KDE Project has done a very poor job in communicating our policy on releasing binary packages. I say this because as the primary contact on the release blurbs, I am the one that gets swamped with emails asking "where is
insert-your-distro package?" and "how does this package work?" and "why are you discriminating against that-distro?" These emails obviously stem from the (incorrect) belief that the KDE Project is responsible for creating those packages. The following document will hopefully clear up just what our policy is in this situation.
KDE Package Policy Explained
The KDE Project only releases source code. Period. When we make a
release, we package up our code into source code archives (.tar.bz2)
and put them on our FTP
server. Those are the only packages that we release and
support.
We do recognize, however, that most people want binary packages for
their particular distribution or platform. As a result, in the days
before a release, we make the source packages available to "packagers"
who then create binary packages from them. The packagers send us
their results and we put them up on our FTP site and mirrors for the
convenience of our users.
This explains why some packages are available immediately and some
take awhile to appear. While we do "pre-release" the source packages to packagers
with ample time to create the binaries, sometimes a few packagers are
busy and they don't upload their packages in time for the release
date.
In the case of Linux distributions, the packagers are the Linux
companies themselves. For instance, if you inspect a SuSE RPM from
our FTP site, you will see that it was created by SuSE. Mandrake,
Caldera, and Slackware all do the same. This ensures that the RPMs
fit into the distribution in the way that it was intended, rather than
as a third-party "add-on".
We also accept some binary packages from individuals where the
companies or groups behind the platform do not distribute KDE
themselves, and so individual volunteers contribute packages to our
FTP server. Examples are cases like Tru64, *BSD, Solaris or HP-UX (or
similar).
The Red Hat packages are a special case in that while the company
does distribute KDE, they don't officially make the binary
packages that are found on our FTP server. In prior releases, the
Red Hat packages were created by a Red Hat employee packaging KDE in his
spare time. When his other responsibilities (the ones that he was
paid to do) took precedence, the KDE packages were (understandably)
slow in coming. Creating packages is very hard work, so we don't
fault him for this. As a stop-gap measure, we are looking for a Red Hat user to contribute binary packages for 2.1.1. Stay tuned.
The Future
We are looking into changing this policy in the future.
Rather than getting the packages from the vendors and putting them on
our FTP site, it might be best if the vendors put them on their own
sites and we just pointed to them. This would have the advantages of
freeing up bandwidth on our servers (which are always overloaded on
release days) and making it clear where the responsibility of support
lies.
Thank you,
Kurt Granroth <granroth@kde.org>
<
|
>
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
|
Over 40 comments listed.
Printing out index only. |
Re: KDE Package Policy Explained
by Eric Laffoon on Tuesday 10/Apr/2001, @17:16
|
Three cheers! This message needs to be delivered. Sometimes I cruise the newsgroups and answer a few questions. Very often questions go like this. "I just installed KDE on Linux 7.0 and it doesn't do such and such". That and the whining about where packages for a distro are. It often seems as if Linux is no longer a community but two communties. One that produces things and the one that berates the other for not doing it to their expectations.
It should be noted that packaging is no small deal. I've said many times there would be much less code if KDE had to focus on all the binary packages for people. In the Quanta project we had more problems with donated binaries than anything else. I am very happy now NOT posting binaries. Distros are handling it and and life is smoother.
I strongly advocate that the binary packages are moved to the distros!!! I can see no reason why I should have to wait several days to get a reasonable bandwidth where my DSL is faster than a dial up. Also I really get tired of people whining about how KDE developers are shorting them. It should be posted in big letters and very clearly. YOUR DISTRO IS RESPONSIBLE FOR BINARIES.
|
[
Reply To This | View ]
|
|
|
how about making upgrades easier
by sarang on Tuesday 10/Apr/2001, @19:00
|
I always wonder.. why do I have to upgrade the _entire_ KDE just to get that ripper module inside konqueror working, or to get the latest bug-fixes in KMail, or to get latest Konqueror for that matter!
So, it would be really nice if we can upgrade the following components sepeartely:
1. KDE-Base
2. KDE-Apps
3. KMail
4. Konqueror
2,3&4 obviously depend on 1. But their development should go on w.r.t latest stable version of KDE-Base. Just like other applications (Quanta, Aethera etc.) I know konqueror and kmail are deeply integrated, but there has to be some solution to this! maybe the parts of KDE-Base used by KMail and konqi could be upgraded when 1> KDE-Base is upgraded or 2> KMail/Konqi are upgraded. I am not totally sure.. but this is just food for thought. IMHO, KDE development is going way fast and thats excellent.. but the users loose in the sense that they have to upgrade the whole KDE every 2 months!
Also, it'll be cool if we were able to install KIOSlaves dynamically thru a GUI in KControl. Thus, if I come up with a cool IOSlave, I can put it up on my website and anybody can download it and install it and the entire KDE will be able to use it!
The way things are right now, the whole modularity is of no use to a normal user coz he/she cannot upgrade just kmail or just konqueror or add that new cool IOSlave!
does anybody have any solutions for this problem? If this continues, we might just end up with the developers and enthusiasts (with a good connection) remaining up2date with KDE and others using an ages-old KDE!
sarang
|
[
Reply To This | View ]
|
|
|
RedHat RPMS
by Carl Russmann on Tuesday 10/Apr/2001, @20:04
|
I've found rpms for KDE 2.1.1 in the RedHat rawhide tree. To install them, I needed several other packages, but after all was said and done, it's all working fine on my RH7 box. Probably not good for those with limited bandwidth, though...
|
[
Reply To This | View ]
|
|
|
Hypocrisy?
by underthumb on Tuesday 10/Apr/2001, @21:33
|
"The KDE Project only releases source code. Period."
Interesting. Let's take a peek at the <a href="http://www.kde.org/whatiskde/index.html">goals of the KDE project</a>:
"...the lack of an easy to use contemporary desktop environment for UNIX has prevented UNIX from finding its way onto the desktops of the <b>typical computer user</b> in offices and homes...It is our hope that the combination UNIX/KDE will finally bring the same open, reliable, stable and monopoly free computing to the <b>average computer user</b>."
So tell me, does KDE hope to bring its oh-so-easy-to-use environment to the "average computer user" by only releasing the <i>source code</i>? There's a cognitive disconnect here, and one that needs to be seriously examined.
In fact, if KDE's goal is to win the desktop space, then they should actually make this their first priority, in both development and devliery. Binaries should be released <i>first</i>, and they should be released simultaneously for all major Linux distributions. Furthermore, the development of said binaries should not be outsourced, or in the least should be tested by KDE developers.
It seems KDE feels its responsibility ends where a users desktop experience actually begins. Mr.
Granroth identified wanting to move binaries off of the KDE servers so users would know, in essence, that it wasn't their fault if things didn't work! This sort of hands-off hacker ethic has no place in an ostensibly user-centric project.
|
[
Reply To This | View ]
|
|
|
Re: KDE Package Policy Explained
by Peter Kruse on Tuesday 10/Apr/2001, @23:51
|
This is only half of the truth, because
in your source code distribution you
have the /debian directories in every
part of KDE which are
only needed for generating the .deb
package, and I am glad that you add this
directory.
cheers
|
[
Reply To This | View ]
|
|
|
Re: KDE Package Policy Explained
by Henry Stanaland on Wednesday 11/Apr/2001, @02:16
|
Pray the Lord that RedCarpet or Eazel get their package upgrading stuff working so that we won't have to worry about this anymore!
|
[
Reply To This | View ]
|
L.S.D : Slightly off topic, but not that much...
by Count Zero on Wednesday 11/Apr/2001, @03:08
|
I believe that the source of the problem lies in the fragmentation of Linux in Distributions. Not that I propose that there shouldn't be distributions: just that each should not fragment Linux creating its own little universe.
More than the LSB (Linux Standard Base) , a standard Linux distribution should be created, as is the case for FreeBSD. This should be created and managed in an open source fashion, and should become freely available via the internet. Let's refer to it as Linux Standard Distro (LSD) for the rest of my post. This distro should also have a standard package management system, with automatic dependecies dissolvement (sounds a little like Debian? Wait, there's more).
The key point is this: commercial distributions should adopt this LSD, and built on top of it their value added thingies, like fancy installers, package managers, documentation, services, support, the whole lot.
Programmers and packagers then will only have to support ONE PLATFORM: the LSD platform. The commercial distribution add-ons will not affect the programming enviroment. All distros will all have the same gcc version, the same glibc, the same package managment system etc etc.
Some Linux advocates will mumble something about 'freedom of choice', and 'variety is the spice of life' etc, and point out that a single agreed LSD is a "bad thing". This, I think, is based on a misunderstanding of the whole 'freedom of choice', 'DIY' thing.
In fact, an LSD platform would *increase* freedom of choise. For example: a user won't be tied anymore to a particular distro's packaging system for binaries, as is the case now. All LSD applications will be at his disposal whatever distrubition he chooses to run. Another example: If someone solved a problem in his LSD, the solution will be applicable to every other LSD. As is the case now, you often find that advice on how to do so and so on Mandrake, for example, doesn't apply to Debian.
And, most important of all, Distributions will be focused to provide what they ought to provide, anyway: value added services and add-ons. Nowadays, they strive with assembling packages and stuff together, and perform pourly on the added value part: I mean it took them three years to get a decent installer program for christ's sake (and many distro's still lack one).
It's not a distribution's job to decide the filesystem hierarchy, or the config files format, not even to decide what gcc version the users should be using. That should be a standard on any self-respecting O.S.This is the way FreeBSD works already, yet FreeBSD lacks distributions (there is only the FreeBSD standard distribution). I think, my proposed scheme, combines the benefits of the FreeBSD standard base, with the added value that Linux Distributions provide.
P.S Just my 0.2$.
P.S 2 The KDE 2.1.1 announcement on kde.org reads:
"On March 27th, 2001, the KDE Project released KDE 2.1.1, a powerful and easy-to-use Internet-enabled desktop for Linux."
Since KDE also runs happily on BSD, Solaris, etc, shouldn't that be "for Unix"? Let's not alienate other users.
P.S 3 Keep up the good work.
|
[
Reply To This | View ]
|
|
|
Re: KDE Package Policy Explained
by Joseph Nicholson on Wednesday 11/Apr/2001, @11:04
|
1st off- Hat's off to all the developers and volunteers worldwide. Your hard work does not go unnoticed or unappreciated! You've made the transition from Windows to Linux so easy for many of my friends!
As far as I'm concerned you guys have better things to do than compile packages for every distribution. As a Helpful Hint, why not have direct links on the front page to the latest (unofficial or not) updated binaries ftp sites?
My big bone is with the distributions. I'll grant that for $30 you get quite a huge assortment of software. I can't complain about that. What I DO complain about - and many others is the whole broken libraries issue with Mandrake, Red Hat, et al. To get up to KDE 2.1.1 (Mandrake) there were (fortunately!) a few kind individuals out there who built their own packages to get past the Mandrake 7.2 glibc_2.2 update problem. Ditto for a few hundred other packages as well. If one or two people can compile all these packages, why can't one of Mandrakes' PAID programmers do this right?
I PAID for the email tech support (through McMillan Publishers) and only got an auto-bot response for the glibc update problem. I scoured the newsgroups and linux sites and never could get a clear answer about the updates (SORRY fellas- using rpm -Uvh --force --nodeps glibc* is NEVER a good idea!). I learned that the hard way when forcing an install of Star Office 5.0 back in the days of SuSE 5.3 (libc5). Broke a lot!
So distributors who expect us to pay good money for this software- GET ON THE BALL! You won't exactly win people over w/ these incompatibility issues vis a vis M$FT and may give a lot of people reason to switch back.
Oh, and for those of you having trouble with Mandrake 7.2 updates- try this site :::
http://www.pclinuxonline.com/
Here you'll find updates quicker than they come out on Manrakes' ''Cooker.'' And they WORK even if you still have glibc_2.1 on your system!
Many thanks to the guy who runs this site!
And kudos to the KDE developers!
_Joe
|
[
Reply To This | View ]
|
Re: KDE Package Policy Explained
by ne... on Wednesday 11/Apr/2001, @12:45
|
WRT distributors providing binaries, I think we
have to realize they can only support what they
provide. If they do not provide KDE 2 in their
distribution, they are not obligated to provide
binaries as add-ons. If they do, we should be
grateful. Now if KDE 2 is a bugfix for KDE 1, I
would say they are obligated to provide binaries.
Meanwhile, as time consuming as compiling source
is, it is still the best option. Just my 2 kopeks
worth.
|
[
Reply To This | View ]
|
Re: KDE Package Policy Explained
by Bruce Jensen on Wednesday 11/Apr/2001, @14:25
|
This whole topic is rather moot... meaning that the folks at kde.org don't really need to explain or justify why they do things the way they do.
Given the fact that a few here are fairly concerned about not having a package available for their particular distribution, I would suggest to them to learn a bit more about linux... especially when it comes to building software from source. It is not difficult and you will benefit wholly in the long run.
RPM's are something of a misnomer. On the surface they appear to be the 'saving grace' when it comes to software management. I, however, avoid them like the plague. Why? Because RPM only lives up to it's *full* promise by meeting all of the conditions below:
1. Anything and everything you have installed was delivered via RPM.
2. Anything and everything you want to have has an RPM available for your specific linux distro... even rpm's that account for changes in core libraries that the given package may require, i.e., glibc, blah, blah, blah...
3. The rpm's for your distro, assuming they exist, have been *tested* and are *supported* by your distro vendor. Good luck.
4. The rpm's were build with the options that you specifically need/want.
By default, Linux Mandrake 7.2 ships with KDE 2.0, broken kde1 libs, and a fragmented QT 1.44/QT 2.2.1.
On my Linux Mandrake 7.2 box, I have both KDE 2.1.1 and KDE 1.1.2 installed (from source) with a clean Qt 1.45/QT 2.3.0 configured to my specs.
Anyways, I'm getting a bit off topic. Learn how to configure, make, and install from source... not only is it the overwhemingly most common distribution method (DUH!!!)... you shall be rewarded in the long run.
Cheers,
-Bruce
|
[
Reply To This | View ]
|
|
|
Re: KDE Package Policy Explained
by Jason Hanford-Smith on Wednesday 11/Apr/2001, @16:36
|
My personal belief would be that the KDE group should be at least concerned that the binaries being distributed pay them good lip-service.
To not be involved, even with just a cursory nod of approval, with the binary releases can lead to severe issues that would only blacken the "KDE" name.
A minor annoyance I have is with the Caldera binaries that have consistently missed out the kdeadmin RPMs in (I believe) all of their KDE 2.x releases. To get the full complement, I have to resort to source compilation. This is something that should be flagged before release. A binary distribution should at least meet the same expectations that a source compilation would give, including not requiring additional libs etc, if the standard compilation would not require them also.
My tuppence worth has hereby ended...
-- Jason
|
[
Reply To This | View ]
|
Re: KDE Package Policy Explained
by Anthony Moulen on Thursday 19/Apr/2001, @07:40
|
Lets get real. If you don't want to deal with making your own package either wait on your distribution to make an update, or wait for the next version of your distribution. This whole I want it now attitude is counter-productive. Lets be grateful that they even make KDE at all. I really like KDE a lot, and I know I get impatient for the next new feature or next new version, and even keep a copy of the CVS tree just so I can get that next neat new thing 3 days before anyone else on my block (although probably no one else even runs KDE). But I don't expect anyone to make it simple for me. If I can't wait for the distributions to do their thing, then it is my problem and only my problem.
I think that the statement that KDE made was very up front and very to the point. It is right that they shouldn't be in the packaging business. I will only say this. I think KDE should build one binary package for Linux and maybe one for the next largest platform. This binary package should be built with the lowest common library in current distribution, and should be placed in /opt. If you decide to get this package you take the responsibility of piecing it into your distribution. This package should have an easy installer something similar to the Loki installer. Again if you choose to go this route you take the responsibility for doing so. Once installed and configured the upgrade should be straight forward, a simply click on the updater and a check of the root password. I don't think that KDE should get into the game of locating packages and dealing with the different distributions. What would be nice is if this package distributor, were builts dynamically enough to allow for perhaps XML configuration files which the distributions could manipulate into their own setup, and then also run an external applet to update the distribution's package database. But again it would be the distributions responsibility to take this additional step, and the only option that the general person would have if they don't want to wait for the distribution is the centrally managed binary tree.
Again I think it isn't KDE's responsibility, and I think that in the long run we are getting a lot for the litttle that many of us give back. It seems very ungrateful to respond in this way saying that windows can do X or Y why doesn't KDE do that. WHen in reality Linux can do that, it just isn't managed at the KDE level.
|
[
Reply To This | View ]
|
Re: KDE Package Policy Explained
by Anthony Moulen on Thursday 19/Apr/2001, @07:41
|
Lets get real. If you don't want to deal with making your own package either wait on your distribution to make an update, or wait for the next version of your distribution. This whole I want it now attitude is counter-productive. Lets be grateful that they even make KDE at all. I really like KDE a lot, and I know I get impatient for the next new feature or next new version, and even keep a copy of the CVS tree just so I can get that next neat new thing 3 days before anyone else on my block (although probably no one else even runs KDE). But I don't expect anyone to make it simple for me. If I can't wait for the distributions to do their thing, then it is my problem and only my problem.
I think that the statement that KDE made was very up front and very to the point. It is right that they shouldn't be in the packaging business. I will only say this. I think KDE should build one binary package for Linux and maybe one for the next largest platform. This binary package should be built with the lowest common library in current distribution, and should be placed in /opt. If you decide to get this package you take the responsibility of piecing it into your distribution. This package should have an easy installer something similar to the Loki installer. Again if you choose to go this route you take the responsibility for doing so. Once installed and configured the upgrade should be straight forward, a simply click on the updater and a check of the root password. I don't think that KDE should get into the game of locating packages and dealing with the different distributions. What would be nice is if this package distributor, were builts dynamically enough to allow for perhaps XML configuration files which the distributions could manipulate into their own setup, and then also run an external applet to update the distribution's package database. But again it would be the distributions responsibility to take this additional step, and the only option that the general person would have if they don't want to wait for the distribution is the centrally managed binary tree.
Again I think it isn't KDE's responsibility, and I think that in the long run we are getting a lot for the litttle that many of us give back. It seems very ungrateful to respond in this way saying that windows can do X or Y why doesn't KDE do that. WHen in reality Linux can do that, it just isn't managed at the KDE level.
|
[
Reply To This | View ]
|
Interesting issue...
by Jesse on Thursday 19/Apr/2001, @22:59
|
First off as a KDE user, I completely agree with this policy. Binary packaging across all of Unix today is not a trivial task. This decesion makes the most sense.
Secondly, for all those saying "it is free, this is what you get"(and variations of), you are repeating exactly what Microsoft says. You are indeed proving points made on the MS "Linux myths" page. That free software has no quality assurance, is not easy to use, and you have to be a programmer to install it.
Now instead of bitching and whining, lets see if there are any ways of improving the situation in the future...
Well, this looks like a perfect situation for an commercial entity to fill a niche. How would KDE developers feel about a company who tests, packages, and distributes KDE binaries? Maybe with an official KDE project blessing? (ewwh blessed Kandalf pee?)
Of course this would lead to the company not packaging a flavor of *n?x if it is not econmoically viable...
Another nots-so-hard solution is simply have the the distrubitors do the packaging as they do now...But informally require them to make those packages public in a certain amount of time from a release, with maybe some minimal testing done. In exchange, the KDE project will link to their site in a nice prominent "we think these guys make decent packages, and they get our seal of aproval" section. Otherwise, the link goes in the "oh yea, you might find binaries here but they might be crap" section.
|
[
Reply To This | View ]
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|
![[KDE Dot News]](http://www.kde.org/dot/Images/kdedotnews.gif)
