KDE Package Policy Explained

Wednesday, 11 April 2001 | Kgranroth

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>

Comments:

Re: KDE Package Policy Explained - Eric Laffoon - 2001-04-11

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.

Re: KDE Package Policy Explained - Iuri Fiedoruk - 2001-04-11

That's why I want change from RedHat to Mandrake. If my distro don't make what I want, and I don't pay for them do this (as I got the install from a magazine or from iso files), I must be quiet and find someone who do the job. But if you payied for your distro, complain about not having the rpms you want! But complai with the right people, ok? :)

how about making upgrades easier - sarang - 2001-04-11

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

Re: how about making upgrades easier - Michael O'Henly - 2001-04-11

> 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! Gotta agree with this. Complaining about users not understanding that vendors are responsible for binary packages may be justified but it's also missing the point. Are you (KDE developers) not concerned that your hard work is lost on many who could benefit from it the most? The promise of KDE is ease of use -- and the pain of updating is an "ease of use" issue! I use Linux-Mandrake, a distro that has contributed a great deal to KDE. But even Mandrake can't seem to get it right when it comes to updates. They post the binaries with little or no documentation -- 2.1.1 appeared without even a README explaining how to uninstall older versions and replace with newer, how to deal with dependencies, etc. The Mandrake mailing lists are full of posts from frustrated users, many of whom end up reinstalling the whole OS because their KDE update went off the rails. KDE is frankly rocking the *nix world right now with its development schedule. It would be great if a mechanism could be developed that would make it easier for average users to actually use these frequent updates.

Re: how about making upgrades easier - rsv - 2001-04-11

Very true! I am using SuSE linux 7.0 (previously used RH6.2, so had to get used to SuSE first). I always end up downloading a version of kde just when the next version is released. It takes nearly 2 nights and a fat phone bill (coupled with angry relatives complaining that the phone is engaged) to download kde fully. Couldn't get the sources to compile (I saw the solution in the compilation faq tho'), so I used the SuSE rpms. These weren't very friendly either. I finished downloading kde2.1 just when 2.1.1 was released. Then I see reviews of the next kde and curse myself. *damn* I am mostly using konqueror now (works even better than IE bundled with Windows ME, particularly with ftp). Konqueror is great for everyday use, but lacks the one feature I would like, ie a good download manager. I have to switch to windows to use Flashget, which seems to make the best use of the bandwidth available to me. Is there a download manager for kde2.1? I used Caitoo from kde1.2 but did not like it much. My first post to the dot using konqueror.

download manager - Louis - 2001-04-11

Hi, there are several good download managers (with stop/restart in case connection breaks) on Linux. a text based is wget which is very reliable. I believe there are front-ends for it, go take a look at apps.kde.org. The one I use is 'Downloader for X' (nt) which is not kde and not wget but easy to use: <a href="http://www.krasu.ru/soft/chuchelo/">http://www.krasu.ru/soft/chuchelo/</a> don't use Win for theese tasks because it is no good staying 2 nights online whith that OS, unless you like getting in trouble ;-) have fun, Louis

Re: how about making upgrades easier - Craig Black - 2001-04-11

The coolest downloader i use is kwebget. It works great for grabing whole ftp sites. You can pick it up here. <a href="http://www.kpage.de/en/index.html">http://www.kpage.de/en/index.html</a> Craig

Re: how about making upgrades easier - Amibug - 2001-04-11

I think some of us are missing the point that you dont _have_ to update KDE if you dont want to. Just because 2.1.1 comes out 2 months after 2.1 it dosent mean you _have_ to download it. You can adopt a policy of downloading every second or third release. Sure updates could be compiled for older versions of KDE but that would create quite a bit more work, and at any rate its up to the Distributions to do that, not KDE

Re: how about making upgrades easier - Johan Veenstra - 2001-04-11

You may want to look into compiling KDE from source. Once you've downloaded the source, cvsup only gets the changes (and these are compressed as well). About the download manager: wget should be all you need, but I suspect your ISP is a complete crap, so a download manager could bbe usefull. Johan V.

Re: how about making upgrades easier - Aaron J. Seigo - 2001-04-11

Well, I obviously don't speak for the KDE developers, but here is my take on it.... The KDE developers are just that: developers. Their _self appointed_ (e.g. voluntary) task is to create this tremendous architecture which all of humanity is free to benefit from. So, why don't they extend this just a bit further and provide actual binaries? Here are three reasons that I can think of: 1) TIME. They are already extraordinarily busy creating the technology. Would you prefer development slowed down significantly, or that people would do what they do not enjoy doing thereby stripping them of the joy they find in this pursuit (and increasing the odds that they will stop)? 2) EXPERTISE. The organizations behind each Linux distribution, BSD variant and commercial Unix all create their own environments. For the KDE developers to take on the task of supporting these operating systems with binaries is not only doing the job of these distributors, but means that the KDE people would have to work with all the iodiosyncracies of each OS. Every OS has its own way of doing things and therefore the different sets of packages will and do vary. Who knows the OS best and is therefore in the best position to create binary distributions for it? Why, the companies who make them in first place. 3) FAIRNESS. To officially provide binaries for any given OS, but not for others, would imply a favoritism that is not a part of the KDE project. Within KDE all *nix, *BSD and Linux systems are treated with interest (assuming that there are KDE'ers on that given system). The amount of work that goes into making sure KDE builds on a wide variety of platforms is very impressive. Therefore, if the KDE team themselves can not provide quality binaries for each and every supported system themselves, I think it is a good idea to treat all of them equally and request that either the OS manufacturers themselves or interested users create the binary packages. Finally... remember. There is no body stopping you as a loyal user of your operating system from stepping up to the plate and creating wonderful binary distributions of KDE. In fact, this would probably be more than welcomed by your fellow users if your OS provider isn't doing their job well. This is how debian, HP/UX, Solaris and (to my knowledge) FreeBSD get their binaries: users stepping up to the challenge. Around and within the KDE project there are programmers, artists, documenters, translators, testers..... and there are packagers. I think this only makes sense. I also think that with enough encouragement from that other group of KDE people, the USERS, the OS manufacturers can and will step up to the plate and offer quality KDE binary packages. Vote with your voice and with your dollars, and perhaps even some of your own energy. That is how this world of Open Source Software works....

Re: how about making upgrades easier - not me - 2001-04-11

I don't think an IOSlave installer would be hard to make. Just a shell script could do it, I think. That's pretty easy to install - just type the script's name at the bash prompt and you're done. A GUI would be nice, but KControl already has too many panels (or maybe they're just badly organized), and a shell script would do the job nicely.

Re: how about making upgrades easier - greg - 2001-04-11

I seriously hope linux (as in everything GNU/Linux) is as easy to update as clicking "Linux-Update." But seriously, when I look at things like Loki's demo installer/updater, it only makes me feal like everything could be that easy... But maybe we need a stronger Linux Standards Base first... and some more general standardization...

Re: how about making upgrades easier - Eric Laffoon - 2001-04-11

> 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! It depends on whether a fix is back ported or if a program is built to a base specification. It's possible to build to KDE 2.0 spces or to KDE 2.1.1 or even 2.2 pre specification. It is all up to what the author wanted to accomplish. If you wish to take advantage of a new feature then it's libs are required. Here is all you need to upgrade. kdesupport, kdelibs and kdebase in that order. That also gives you konqueror. Kmail is in kdenetwork. That's far from all the packages. > 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! Again I repeat... that is arbitrary. If the io slave is built to your specification (and to my knowlege there has been no substantial change to the base architecture there for a while) then you DON"'T need to upgrade to make it work. > 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! Yes! There is an incredibly simple bandwidth sensitive solution! First let me say this. KDE 2x took a long time to come out. People complained. When I looked at it and realized that it meant that KDE would be able to produce faster releases I got excited. Somehow I failed to imagine that people would begin bitching about it releasing too fast. Here's a clue... it will always take distros time to catch up no matter how fast or slow a program releases. (duh?) However you don't have to upgrade, or you can. For the most part KDE 2.x programs are compatible unless a developer writes to newer or enhanced libs. Pay attention. This will get you the latest bleeding edge KDE with the least bandwidth requirements. It will also work on any system. Grab a copy of Cervisia and compile it. Now this is difficult so pay attention. Extract it using the graphical archiver tool Ark. Go to the directory in konq and use the tools menu to open a console. It will open in your directory. Now type $ ./configure && make $ su [enter root password] # make install Now go to kde.org and get the information for cvs and enter it into Cervisa. You can now get only the updated files at any time. With RPMs and tar files you have to get them all. After your first build you will only recompile what is affected by the updates. This is fast and clean. You can use Cervisia to update to a tag level for fixes or let 'er rip for bleeding edge. Oh, one more command for cvs. on the first build or when directories are added you have one additional command. $ make -f Makefile.cvs I have also seen shell scripts to handle this and they are easy to write. I do recommend you build your KDE in a seperate directory and kde.org has files explaining how to run two KDEs. Once you get it started you can update at any time using graphical tools and it is bandwidth sensitive and quick. As a side note, I came to Linux from OS/2 at the end of 1999 and had been mostly working with languages like REXX and Basic. So compiling programs in Linux was a foreign thing to me... but it is not hard and to my experience has far less problems than running RPMs. Enjoy Extreme KDE... build it from CVS. ;-)

Re: how about making upgrades easier - sarang - 2001-04-11

>It is all up to what the author wanted to accomplish. If you wish to take advantage of a new feature then it's libs are required. and the problem is that every developer has updated his/her machine to the latest and greatest KDE (even CVS probably as you suggest in the end). What about the users of the application? In simple english "you won't get next version of KMail unless you upgrade to KDE 2.2". Now suppose next version of KMail has "IMAP" as the new feature.. does it have anything to do with KDE 2.2? There could be millions of KDE 2.0.1 users our there.. and they'll never get KMail with IMAP unless they go through the pain of upgrading the entire KDE. Similarly with konqueror.. A lot of my friends still are on default LM7.2 which has KDE 2.0.1.. they keep complaining about Konqueror bugs which are fixed long time back.. but the problem is, konqueror is not released outside of KDE base packages.. hence to get latest konqi, full upgrade is needed! >Here is all you need to upgrade. kdesupport, kdelibs and kdebase in that order. That also gives you konqueror. Kmail is in kdenetwork. That's far from all the packages. why isn't konqueror seperate and developed individually? As I understand konqueror uses KParts (khtml etc.) to show the contents.. then why does teh konqueror code itself needs to be in the base libaries? Also, why isn't konqueror released periodically with latest and greatest khtml (since browsing is the main use of konqueror) which will upgrade the khtml the user installed with the KDE he/she has. Similarly, its clear that KMail is outside of KDE's base.. then why can't we have KMail released seperately just like Quanta, Aethera etc? On the other hand, the release schedules of konqueror, kmail etc. can be synchronized with those of KDE-base and we'll get the same effect as we get now.. i.e. KDE2.2 will come with KMail 1.4, konqueror 2.2 etc.. but people preferring to only upgrade KMail can do so too.. Now the question arises of new features.. to tackle that, KDE people definitely need to find a solution so that applications can automagically use the new feature of a newer KDE-base if it exists, else switch to old one. For eg., KDE 2.2 comes out with new printing.. there has to be some way so that KMail will automatically use this new printing scheme (read classes) instead of the old QPrinter if and when it finds teh new libraries installed. KDE has a lot of talended people and I am sure someone out there will be able to find a solution! >If the io slave is built to your specification (and to my knowlege there has been no substantial change to the base architecture there for a while) then you DON"'T need to upgrade to make it work. then why don't we get the latest and greatest cd ripping io-slave? why don't we have it for KDE 2.0.1 users? >Pay attention. This will get you the la [snip] You didn't get my point Eric. Let me first tell you that I am using KDE 2.1.1 on my LM 7.2.. I am pro in CS and have been using linux/unix for 4-5 years. I can very well download RPMS, install then and figure out problems myself. However, here, I am trying to solve the problem for newbies and even normal users or expert users who want to use linux for production purposes and not for playing with it. You cannot expect a corporation to upgarde KDE on all of its 1000s of machines every 2 months! The solution of getting latest CVS and compiling is perfect for KDE developers themseleves.. but do you think of users?? Anybody who is doing productive work on his/her machine dosn't want to be on the CVS bleeding edge to have an unstable desktop! > has far less problems than running RPMs. this is plaing wrong. I have been using RPMs and never had any problems with them. The reason being I always use RPMs provided by Mandrake. Everything is perfect then. Also, the whole point of KDE being user-friendly goes away when u ask u're users to compile!! its easy for devlopers and pros like us, but put u'reself in u're grandma's shoes and then think of it.. and if u dono't want to do that, then our motives are totally different! Ok back to the main point.. some possible solutions: -one solution to this seems to be major API changes be allowed only in distant releases. For eg. any application written for 2.0 - 2.1.1 should run w/o problems on 2.x.. this will ensure that atleast for 9 months u can afford to not upgrade ;) -another is to provide backward compatible code.. for eg. provide KPrinter library for KDE 2.0 so that applications written for KDE 2.2 work with 2.0 -segregating base and apps can reduce this problem to a certain extent. Major KDE releases should be once a year with dates synchronized such that all applications that form KDE are released with these major upgrades. Minor upgrades could be frequent and should only include base library package upgrades. The application developers should make sure that applications run across the minor KDE revision. One advantage would be that it'll be easier for people to upgrade as they'll have to deal with fewer RPMs. Consider this: I have KDE 2.0.. new kmail comes out.. but they say I need to upgrade KDE-base packages coz it has new printing functionality.. so I go out and download 2-3 RPMs and upgrade my KDE base to 2.2.. then kmail installs peacefully and works perfectly. All other apps continue working as before since base libaries are always backward compatible (or rather should always be!!) >I failed to imagine that people would begin bitching about it releasing too fast I am not bitching.. I love the pace at which KDE is developing.. but that pace shouldn't kill it either right? If the user base decreases because of the tremendous confusion between releases and the pain to upgrade, then KDE will loose its following... which means Linux will loose its following.. and that shouldn't happen. Hence I am raising this issue here. Some how this entire development needs to be synchronized and some new solution has to come out to maximise the time between full upgrdes for people. One year life-cycle would be a good thing IMHO. You can expect people using linux to upgrade once a year. Please guys, think of somethign cool to solve this issue. I request someone who is on KDE lists to post on the lists so that KDE developers read this discussion and contribute. I am not subscribed so can't do that. thanks! sarang

Re: how about making upgrades easier - Guillaume Laurent - 2001-04-11

> Now suppose next version of KMail has "IMAP" as the new feature.. does it have anything to do with KDE 2.2? Yes. It could use new stuff from the base. Look, what you suggest is completely unrealistic and would lead to total chaos in no time. Right now, upgrading KDE is very simple : download everything, recompile/install everything. That may take a long time, but it's still very simple. And most importantly it's simple to manage both from the developper and the user's point of view. Compare this with schemes like "upgrade this package to this version and that package to that version if you need feature X in package Y" etc... By the time you figure out all the dependencies (which most of the time will end up being pretty close to "the whole shebang", you'd have downloaded everything already. Plus it would be a total nightmare for developpers and package builders.

Re: how about making upgrades easier - Nathan - 2001-04-11

You're right, this is totally unrealistic. You can't expect to upgrade an application without upgrading all of its dependencies! This is why you can't upgrade Adobe Acrobat without buying a new copy of Windows, right? This is why you have to recompile all of Red Hat from source entirely every time you upgrade to a new version of KBiff, right? Of course not! There is a huge time savings from only upgrading packages X,Y, and Z instead of the whole desktop. If I want a new KMail feature I shouldn't have to upgrade my entire desktop, possible breaking the configuration files for konqueror, knode, etc. And "just" downloading everything and recompiling everything is a huge pain in the ass IMHO. I have yet to successfully compile KDE from start to finish without hitting all kinds of strange problems. This is *not* the solution if you really expect to be the "user-friendly" desktop that brings Linux to the masses. It would be nice of the developers to at *least* document which config files are broken by new releases, letting the user know what kind of bumps to expect in the upgrade. Sorry if I'm ranting, but I've spent *far* more time nursing KDE upgrades along than I ever spent rebooting my Windows machine. It's getting *very* frustrating.

Re: how about making upgrades easier - not me - 2001-04-11

>And "just" downloading everything and recompiling everything is a huge pain in the ass IMHO. I have yet to successfully compile KDE from start to finish without hitting all kinds of strange problems. I hear you! I've never been able to get KDE to compile. >Sorry if I'm ranting, but I've spent *far* more time nursing KDE upgrades along than I ever spent rebooting my Windows machine. Yeah, you sound like me, before I switched to Debian. Then suddenly, all my KDE problems magically went away. Now I get KDE upgrades *before* they've been announced on Slashdot, and they always install over the previous version perfectly, keeping all of my settings. I even have anti-aliased text in KDE, with _NO_ effort whatsoever! A simple command (apt-get install task-kde) finds, downloads, installs, and configures KDE _and_ all its dependencies, in one gigantic automated step! apt-get and kde.debian.net are the greatest! Sorry if I sound like a broken record here, but I just can't get over the incredible coolness of apt-get. I recommend that you try Debian out (or for an easier graphical install, try that Progeny Debian that was just released).

Re: how about making upgrades easier - Guillaume Laurent - 2001-04-12

Something like you describe will probably happen in the near future, but right now it's perfectly understandable that "everything" is just moving forward, from base to apps. The base libs are bound to stabilize (API-wise, e.g. no new features) while the apps will keep on evolving. Right now it's just not the case, and maintaining two version of each app is a nightmare in the long range. They already do it between each minor releases (2.1 vs 2.2), but fortunately they try to keep it as short as possible, and limit the changes in the "old" branch to critical big fixes only. They don't backport new features and IMHO they are right in not doing so. As for compiling KDE, for me it has always been "tar -xvf ; ./configure; make; make install". The only problems I've had are when I try to use --enable-final, which doesn't work for every packages. It's right though that config file are a serious problem. I had to clean up my ~/.kde several times after a new install.

Re: how about making upgrades easier - Ingo Klöcker - 2001-04-12

>You're right, this is totally unrealistic. You can't expect to upgrade an application without upgrading all of its dependencies! This is why you can't upgrade Adobe Acrobat without buying a new copy of Windows, right? Wrong example ;-) The right example would have been: You can't upgrade M$IE without upgrading a whole lot of the libraries which come with Windows. The only difference is that all new libraries you need are included in the installation package of the new IE whereas with KMail you also have to update kdelibs (because AFAIK some KMail related bugs have been fixed in some kio_slaves which are part of the libs) and maybe kdebase. But I think updating kdelibs could suffice. If OTOH you use the packages provided by some distrubution you maybe have also to install the latest version of QT and some other libs this particular KDE build depends on. But for this the packager is too blame (was it really necessary to use the latest version of QT for this build?) and not the developers. Regards, Ingo

Re: how about making upgrades easier - Michael Häckel - 2001-04-11

Hi, At least for KMail I can explain you why that is not possible. I even though about releasing a separarate version of KMail independant of the KDE release schedule when IMAP is ready for use, but that is no longer possible. Exactely because of IMAP there have been made a few additions to kdelibs to make implementing it much easier and now KMail of course depends on that changes. That is one of the advantages of keeping everything together. If an application needs a new feature in kdelibs this feature can be added and the application is immediately able to use it. Otherwise it would be every time necessary to wait for the next stable release and that would slow down development very much. Regards, Michael Häckel

Re: how about making upgrades easier - Naasking - 2001-04-11

Isn't this supposed to be the benefit of components though? You write components that can operate independently(and can co-operate) so you don't have to upgrade EVERYTHING to add one feature to your suite/app/whatever. You just have to upgrade the component which is dynamically loaded when needed. If the component wasn't there to begin with, it should be just a matter of installing it and having it registered with whatever service links the components with the services they provide. Sure reuse, protection, network transparency are all cool component features too, but the main benefit of componentization is supposed to be complete separation of implementation from interface. If this isn't currently the case, then I'd say it's time to rethink the strategy behind the current component framework.

Re: how about making upgrades easier - Alexander Kuit - 2001-04-12

Wouldn't it be possible to create a statically linked version of KMail?

Re: how about making upgrades easier - Jason Hanford-Smith - 2001-04-12

This whole things helps back up the Minnows(*) argument that GNU/Linux is nothing but a geek toy. The arguments put forward regarding upgrading everything en masse are untenable. To expect your average user to upgrade through successive version (4 in the matter of a few months), is asking too much. If you examine the Windows release schedules, you'll see that although major functionality is brought in on every major release, it doesn't stop major application upgrades in the mean time. And these certainly do not require a complete low-level upgrade. Regarding binary distribution vs. source compilation, let me just say, if you ever seen a genuine newbie (or even a casual computer user) get to grips with Windows Update you'll know that most people are too afraid of "messing around" with what they perceive as a working system. They may need the upgrade, but if something were to go wrong, they wouldn't know how to fix it. Telling these same people to download and compile source code (and try to unravel the compilation error messages !) is ridiculous. Even RPMs should be considered too difficult. There should be no reason why the whole upgrade process can not be handled behind the scenes. The compilation process (if it's to be done) should be hidden behind a GUI. The RPM installation should be hidden behind a GUI. There should be no reason why anyone has to open a command line to upgrade KDE. If this means that a generic installer is created for each binary distribution, this should be a small price to pay for increased ease of use. Just my tuppence worth. --Jason ------------------------------------------- (*)min·now (mn) n., pl. minnow or min·nows. 1. Any of a large group of small, freshwater fishes of the family Cyprinidae, widely used as live bait. 2. Any of a large group of Microsoft Windows users, widely used as live beta testers.

Re: how about making upgrades easier - Ingo Klöcker - 2001-04-12

>If you examine the Windows release schedules, you'll see that although major functionality is brought in on every major release, it doesn't stop major application upgrades in the mean time. And these certainly do not require a complete low-level upgrade. Every new version of M$Office or M$IE installs a lot of new libraries. And you have to reboot several times. If this isn't a low-level upgrade why has Windows to be rebooted? OTOH if you upgrade KDE you don't have to upgrade the kernel or X. Only some libraries and the KDE packages. So upgrading KDE is certainly not low-level. You don't even have to reboot after upgrading. ;-) Regards, Ingo

RedHat RPMS - Carl Russmann - 2001-04-11

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...

Re: RedHat RPMS - Damian Kohlfeld - 2001-04-11

I'm compiling the SRPMS on a RH7 box. Unfortunately it is a minimal install of RedHat, and there are dozens of dependencies.

Re: RedHat RPMS - Miska Sulander - 2001-04-11

Could you provide the URL to Redhat KDE 2.1.1 packages?

rawhide RPMS - darkprok - 2001-04-12

Several other packages? I installed the rawhide binary RPM packages for kde 2.1.1 on my redhat7. It took a whole day. When I got all of the kde and all the packages it depends on I noticed I had downloaded about 86,876K. And the installation was not easy at all. I had to install quite a few new libraries. However many applications on my box depend on the old versions of those libs (notably openssl, openldap). My box runs apache and sendmail and I didn't want to take any chances and break something just to get the latest update of my favourite desktop environment. Although I was finally able to resolve all conflicts I'm not sure if I want to go through that procedure again in a few weeks when kde 2.2 is released.

Hypocrisy? - underthumb - 2001-04-11

"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 typical computer user 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 average computer user." So tell me, does KDE hope to bring its oh-so-easy-to-use environment to the "average computer user" by only releasing the source code? 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 first, 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.

Re: Hypocrisy? - not me - 2001-04-11

It isn't that the KDE project doesn't want to release binaries, it's that it's impractical. If KDE had to support every single distro out there (Red Hat, Caldera, Mandrake, Slackware, SuSE, Debian, and of course lots more) not to mention the several different OSes that KDE will run on (*BSD, Solaris, etc) with binary packages, there would be no time for coding! Besides, they would need access to a free machine that ran each of these, so they could compile. Why should KDE do that when a small army of independent packagers can do it better, faster, cheaper? If there were no packagers working to provide binaries, then the KDE project would have an obligation to release their own binaries. But since all these nice people already do it for them, there's no point. Yes, sometimes the volunteer packagers make mistakes, but would the KDE project really be able to guarantee that their own volunteer packagers would be that much better? I don't see the benefit from the KDE project taking on that enormous burden.

Re: Hypocrisy? - underthumb - 2001-04-11

"It isn't that the KDE project doesn't want to release binaries, it's that it's impractical." Is it more impractical to end users or developers? Are we forgetting the goals of the KDE project? What's really impractical is hoping that the KDE source code will somehow be cobbled together by users or individuals not associated with KDE into something consistently workable. "Why should KDE do that when a small army of independent packagers can do it better, faster, cheaper?" If the "small army" could actually do it better, faster, or cheaper then this news item would not exist. Outsourcing the package creation and then simply not caring/not supporting it is what makes this problematic. It also assures that some distributions get packages first, and that some (such as Red Hat) may not get them at all. The point I'm trying to make is that spending time on the binaries should be an official part of the project. KDE developers should _collaborate_ to make sure that binaries are of the highest quality, and not simply hope that they will be "good enough" in the hands of one busy individual. The biggest argument against this seems to break down to "it's hard," and "we don't want to do this." Well, I'm sorry to sound like a grump, but I just don't have a whole lot of sympathy. This sort of argument could be made against almost any developer-unfriendly activity, such as writing documentation or bug fixing. Unfortunately, both activities are absolutely essential to creating a positive and affirming user experience. Similarly, creating packages that work well, and that have the KDE stamp of approval is part of being a desktop provider.

Re: Hypocrisy? - richie123 - 2001-04-11

It's the job of linux distributions to support KDE packages made for their distro. How could you possibly expect the kde project to know all the various quirks and library differences between every linux distribution?? If you want to blame someone, blame RedHat not putting up the resources to hire a packager to do the job. Do you really want to use a distro that only half-ass supports the best desktop software for linux anyway?

Re: Hypocrisy? - Bernd Gehrmann - 2001-04-11

So, what exactly are *you* doing to create to 'positive and affirming user experience'?

Re: Hypocrisy? - Craig Black - 2001-04-11

I guess you of course will volunteer for kde to create all of those packages. Of course you won't sense your probably a Xamian employee spreading hate. Craig

Re: Hypocrisy? - aleXXX - 2001-04-11

> "It isn't that the KDE project doesn't want to > release binaries, it's that it's impractical." > > Is it more impractical to end users or > developers? Are we forgetting the goals of the > KDE project? In which way did _you_ help KDE to be able to say "_we_ are forgetting" ? IMO the goals of KDE are to deliver a high quality DE to the user and to have fun developping, most of us do it in their spare time. It is simply impossible for us developers to create binary packages for each and every distribution/OS. Bye Alex

Re: Hypocrisy? - Waldo Bastian - 2001-04-11

> It seems KDE feels its responsibility ends where > a users desktop experience actually begins. Well, were we stop, distributions continue. There are numerous distributions all with wonderfull ways of bringing our software to your desktop. Cheers, Waldo

Re: Hypocrisy? -> Reality! - Eric Laffoon - 2001-04-11

There is no denying that it would be nice to have all the packaging covered... but how about reality? Here is reality... 1) Pretty much every vendor modifies their KDE install. Should that be acknowleged or circumvented? 2) KDE is not just a set of applications. It is integrally tied to a user's graphical shell. This means that it has to address start up issues which vary not only between distros but often between point releases of distros. How many dozen times should you have to build your program and get it tested? 3) There are a number of dependency issues such as alsa and SSH, but these are more critical when it comes to compiled binaries. So there are lots of issues introduced here, especially if your install is not vanilla. Here is a thought. Ximian has been at their installer idea for some time and are now heavily financed... yet they do not support (to my knowlege) at this time Mandrake or SuSE. Why? Has anyone here ever tried to make an RPM? I say tried because I know hot shot programmers who tried and gave up! Here's a final consideration. We release Quanta Plus as source but previously had people donating RPMs. I also follow newsgroups. As I see it the biggest problems out there are with RPMs! Personally I'm getting sick of them, but grateful when I need one and it works right. Still they are so easily hosed. Files from one version move to another package... dependencies want me to install beta compilers. No thanks! KDE is not open binary... it is open source. Doesn't that mean anything any more? I would love to see every user convenience... but I would hate to see two to three weeks of hell added to a release to do packaging and half the developers walk away because they are too busy handling support emails to program and it's no longer any fun to develop. If you find this to be a problem I suggest you either get your money back from the KDE developers (hint, they are giving this away) or you pitch in to make your vision reality. Telling them they are hypocrits for not having the resources to pacify you and act on their every idea seems to be missing the spirit of open source!

Re: Hypocrisy? -> Reality! - Eric Laffoon - 2001-04-11

Re: Hypocrisy? -> Reality! - underthumb - 2001-04-11

"1) Pretty much every vendor modifies their KDE install. Should that be acknowleged or circumvented?" Whatever works the best for each distribution. As developers, these and other questions are matters that need to be addressed internally. "KDE is not open binary... it is open source. Doesn't that mean anything any more?" It means that KDE is open source. It doesn't mean anything with regard to this discussion, which is about the focus of the KDE project. Are you or are you not out to create a user-friendly Linux desktop? What is the desktop market? Is it dominated by C++ developers, or people who simply want to get work done? You tell me. And with that in mind, what is more valuable to end-users: source, or binary? "Telling them they are hypocrits for not having the resources to pacify you and act on their every idea seems to be missing the spirit of open source!" I don't expect KDE developers to "pacify" me though I do expect them to give some thought as to the ultimate goals of the KDE project, and just how they expect to get there with an end-user-comes-last mentality when it comes to binary distribution.

Re: Hypocrisy? -> Reality! - Jelmer Feenstra - 2001-04-11

AAAAARGH Is this IE (this is not my computer) being a bitch or am I just plain stupid ?! I just finished a very long reply to the very comment I'm now replying to, and wanted to see how it looked -> preview. Ok, it looks fine, so I hit the browser's back button, overlooking the fact that the add button is on this preview page as well. Comment gone ! I hit forward again : "page expired". Tell me, does IE just plain suck ? I tried this with konqueror and it remembers my comment. Well, I don't feel like thinking about what to reply once more. Sorry. Jelmer Feenstra

Here is the reality... - WorLord - 2001-04-11

The reality here is that Underthumb is, without a doubt, 100% correct. Oh, now I know I've just stepped on the toes of every single Linux user/developer who's been in it for the long run, but that's just the way it goes. See, the problem here are the GOALS that KDE is going for... an "easy to use" or "user-friendly" desktop environment for Linux. Notice that no specific Linux distro is mentioned. (That's the nutshell explanation - Underthumb has quoted it earlier on in the discussion). *If* that is what KDE is _actually_ shooting for, then it's nothing short of functionally retarded for developers to hide their heads in the sand and/or use the "not my job" excuse. Getting the software up and running is the _very first step_ in a user's desktop experience! It's the step that everything _else_ depends on! Not addressing this part of the process or foisting the responsibility of it off on others is pretty much the textbook definition of hypocritical. Publishing just the source code with an announcement, pat on the butt, and a "good luck" message simply _does not cut it_. And questions like "exactly what have *you* done lately" and "how are you helping to contribute" are well beside the point, and all of you who ask this (rather childish) question damn well *know* it's beside the point. And in the (very unlikely) event that you don't understand why this is, then I'll tell you: put simply, *neither myself, or Underthumb, or the legions of would-be KDE users posted a manifesto stating that we would make the Linux desktop more user friendly*. That is why it isn't about my contributions, or Underthumb's contributions, or any other individual's contributions to the project. The people who work on KDE said that they are working on making the Linux desktop a more user-friendly experience, which makes it completely their responsibility for doing so - *especially* with regards to the all-important installation process. My vote is that they should very well stick to that manifesto or change it to reflect the reality of their situation, whatever that reality may be (currently, I think it's "we want to create a user-friendly desktop shell that you'll only get to experience if someone knowledgeable sets it up on your machine.") Binaries (and decisions regarding how and when these binaries are released) should be an integral part of KDE's developmental process. Period. Not to pacify myself or others, not because I want to see the developers suffer, not because everyone who is new to Linux is stupid rather, because KDE said they were working to make things easier, and I'd like them to stick to their word and address what is possibly the biggest user-friendliness issue facing KDE at the moment. If you're going to volunteer to do something, then damn it, put your best efforts into doing it. That's my $0.02, take it for exactly what it's worth. --WorLord (At least we can all rest easy knowing that Gnome has made many more - and far worse -mistakes in the last year or so)

I still don't see it - not me - 2001-04-11

I still do not see _any_ benefit from the KDE project going out and telling all the existing packagers "Thanks, but we don't need you anymore" and doing the whole thing themselves. Look, the KDE project couldn't do a better job itself! First, it would have to go out and get people to do the packaging. Who would do it? The core KDE developers? Not if you still want KDE to be developed! They would have to spend all their time making packages, fixing dependencies, resolving conflicts, answering package-related e-mails, etc. We can rule them out. Should KDE go out and find all new packagers? Who would they draft into their service? It would be really hard to find new packagers. The remaining option would be for KDE to adopt the existing packagers to be part of the KDE project. And this doesn't fix anything! Giving the packagers "honorary KDE developer" status wouldn't suddenly increase the quality of their work, and there's no "KDE stamp of approval" that will magically make packages function better either. The fact is, the current packagers DO work almost as part of the KDE project. They have complete access to all the resources that are available to the developers (as do you, me, and everyone else who has Internet access). I really don't see how to improve the situation. It's not like binaries aren't available, or something! Maybe the RedHat rpms are a week late. I'm sorry, I really am. (I'm sorry for anyone who can't use apt-get) But giving KDE the burden of providing packages, WHEN THERE ARE ALREADY THESE GREAT PEOPLE WHO DO IT, is silly. Sorry for the caps. Bring back HTML posts!

Re: Because you're looking in all the wrong places - WorLord - 2001-04-12

What amazes me about your last post is not how well you criticized what I've said - which you didn't do at all, IMO - but rather, how well you've criticized things I *didn't* say. You've read so much into my post that you missed the boat entirely. Here, let's review: "I still do not see _any_ benefit from the KDE project going out and telling all the existing packagers "Thanks, but we don't need you anymore" and doing the whole thing themselves." Please quote where I suggested that the KDE project do this. (Clue: I didn't). "Look, the KDE project couldn't do a better job itself!" Yes, they could, but I'll get to that in a minute. "First, it would have to go out and get people to do the packaging. Who would do it? The core KDE developers? Not if you still want KDE to be developed!" Oh, don't lay that one down. I ask you, who BETTER is there out there to supervise the compilation of a working binary (notice I didn't say "working binarIES") then the people who WROTE THE PROGRAMS themselves?? After all, it should be blatantly obvious (simply by the program's existence) that they are, shall we say, MORE then familiar with the whole ./configure, make, make install routine. Learning to compile is the first part of learning to code. The first lesson I ever got in C was how to write and _compile_ a working "hello world" program. If they can _write_ it, it should be more then obvious by now that they can successfully _compile_ it. "The fact is, the current packagers DO work almost as part of the KDE project. They have complete access to all the resources that are available to the developers (as do you, me, and everyone else who has Internet access)." And they will probably still make their distro-specific packages regardless of what I'm about to propose. In fact, they will probably make their distro-specific packages BECAUSE of what I'm about to propose. "I really don't see how to improve the situation." That's because you've restricted your options to the point of futility. If you're willing to read it, I'm willing to offer a simple solution: KDE should go the way of Opera, and give the option of a single _statically linked_ binary that is completely distribution inspecific (which is kind of the point of static linking). One huge *.tar.gz file (and it WILL, in all likelihood, be huge), maybe KDE-everything.tar.gz, that unzips to /opt/kde and contains all the lib.xxxxxx.so.x files (and such) required to run a self-sufficient, latest and greatest, shiney and new version of KDE. Perhaps an installation script that unzips the file for the user, and edits the .xinitrd file accordingly (not unlike WindowMaker) - and this is something simple enough even for peons like me to write. Thus endeth all of the problems, and everyone is happy. Would the file be huge? Yes. Yes, it would. But would it provide a simple, reliable, and easy to install version of the Latest KDE (read: a "user-friendly desktop experience")? Yes. Yes, it sure would. (And the idea can even be expanded upon, even! KDE-Barebones.tar.gz would be just KDE and the minimal amount of apps in the core packages. KDE-MidGrade.tar.gz would be business oriented. You get the picture by now, probably.) NOW, whether or not the KDE crew would want to sully their hands with close integration with X or Y distribution or package format is entirely up to them, and a different matter altogether. If I were on the team, I'd vote against such a thing, though - and rightfully so, IMO. While I may believe that it's the KDE crew's responsibility to provide a working binary of their product, I do *not* believe that it's KDE's responsibility to bow and scrape to the various and strange niceties and inconsistencies of the various Linux distributions out there, and at no time have I ever stated or implied such as that. If Mandrake users want a version of KDE that ties in with the Mandrake Menu System and ends in i586, then the Mandrake Packagers can make it (which they will doubtlessly be doing for cooker, anyway). If the debian people want to use apt-get to update their KDE, then I'd say it's up to Debian to provide such things (again, they'll be getting around to this eventually anyway). But I do think that they are fully responsible for offering a *some kind of a working binary distribution of their product* in the interest of remaining true to their aforementioned _Stated Goals_. And I think a single statically linked binary that doesn't care WHAT distro of Linux it gets unzipped to would be just the trick to accomplish this. --WorLord

Say what you mean and mean what you say - not me - 2001-04-12

>What amazes me about your last post is not how well you criticized what I've said - which you didn't do at all, IMO - but rather, how well you've criticized things I *didn't* say. I'm sorry, I misconstrued your statement that "Underthumb is, without a doubt, 100% correct" as indicating that you actually agreed with what he said and were going to back up his argument. You were both apparently arguing that KDE should take on the full responsibility of providing binaries itself. You made no mention of your scheme for KDE to provide a single "official" set of portable binaries. Now that you have, in fact, revealed your scheme in all its glory, I can respond to your actual argument. (by the way, why didn't you just say what you meant in the beginning?) First of all, I agree that of course the developers are the ones who are best suited to compile KDE (although they are not best suited to adapting to the quirks of each and every distribution, which you seem to agree with). However, I think your idea of providing a "single, statically linked binary" is not feasable for other reasons. Here's the problem: KDE is not a single binary (not even close), so how do you propose to make a single statically linked binary out of it? Statically link every component, you say? My God, that's bloatware extreme! KDE memory usage would skyrocket! Only people with _over_ 256 MB of RAM would even be able to _think_ about running a statically linked KDE. A KDE with every component statically linked against QT would be impossible to run. Include QT as a shared library and statically link the rest, you say? Still extreme bloatware. The KDE project would _not_ be doing itself or anyone else a service by providing unusable binaries. Besides, the utterly gigantic tar.gz file would be out of the reach of all but the most persistent modem downloaders. These statically linked binaries would appeal only to a very small audience: Those people who have broadband connections to the Internet and also have truckloads of RAM that they don't mind wasting for no reason. Anyone else who tried these binaries would be repulsed by their large size and insane memory usage, and they would probably think of KDE as bloated and slow from then on. This distribution method works well for Opera, and I think its a great idea in their case. The difference is that Opera is one small binary. KDE is much larger, and is composed of many smaller binaries. This makes static linking impractical. What really should happen is changes should be made in the GNU environment to facilitate moving binaries around much like Windows does. However, the focus of the GNU project has never been and never will be portable binaries, so it is unlikely that this will happen.

Say what you mean and mean what you say - not me - 2001-04-12

Oops! - not me - 2001-04-12

Argh! Stupid IE! Sorry for the repeat post. I wish I could use Linux all the time and never deal with Windows and IE.

Read the text. Don't read into the text. - WorLord - 2001-04-12

"Now that you have, in fact, revealed your scheme in all its glory, I can respond to your actual argument. (by the way, why didn't you just say what you meant in the beginning?)" I *did* say what I meant in the beginning... but I had no idea you'd read quite so much into it. "Here's the problem: KDE is not a single binary (not even close), so how do you propose to make a single statically linked binary out of it?" KDE is a gaggle of programs (executables) that require a flock of files to run (libraries). Provide all of them in one zip (tar.gz) file. Or, ideally, privide a bare-bones, mid-range, and full set of each in separate tar.gz files. "Statically link every component, you say? My God, that's bloatware extreme! KDE memory usage would skyrocket! Only people with _over_ 256 MB of RAM would even be able to _think_ about running a statically linked KDE." Actually, I completely fail to see how the RAM requirements would change one iota. It takes RAM to load the executables + libraries on ANY system. I don't really think it matters *where* those libraries are located on the hard drive. The only difference would be that the static KDE binaries would provide these library files in one single directory (as opposed to how different distributions place them in different spots on the filesystem). Now, there WOULD be wasted resources and redundancies WRT hard drive space; there would be whatever versioin of QT that came with the distribution AND a KDE-provided version of QT in the KDE directory (for example). And this would, undoubtably, make the download bigger. But KDE is already out of reach of most modem users - I think I d/led the 2.1.1 Mandrake Packages at roughly 80M. At that scale, what's another 20M tacked on? For downloads of that scale, I set it to download and go to bed either way, and it's all going to ZIP or CD/R anyway... both of which can handle the size. "The KDE project would _not_ be doing itself or anyone else a service by providing unusable binaries." They would be perfectly usable. Just a bit larger. Whether or not they would be the most _practical_ solution for the _advanced_ Linux user is another matter entirely, and one that falls out of the scope of the argument. I suspect this is exactly where the Cooker/Rawhide/Woody people would step in and do what they've always done best, and I personally would probably wait for that (if for no other reason then to get the Pentium-optimizations that MD packages provide). Does this make more sense, or am I off on understanding how Static things work? --WorLord (a Tisket, a Tasket, a Task Manager)

Re: Read the text. Don't read into the text. - Lubos Lunak - 2001-04-13

The difference between shared and static libraries is that shared libraries are shared, while static are simply included in the executable, and therefore are not shared between different apps. Which means statically linked KDE would multiply memory usage and it would also multiply disk usage ( it wouldn't be another 20M, but maybe another 80M, or more probably 160M, or maybe even 320M, or maybe even more, I'm really not going to find out ). This makes your 'universal static KDE binaries' idea useless and we're back at what's the best thing to do - to let the distros create the right packages ... after all, they get paid to create packages for people, unlike KDE developers, right ?

Re: Read the text. Don't read into the text. - WorLord - 2001-04-13

Hm. Is it then possible to compile it shared, and simply include all the necessary shared *files* (libraries) in the distribution tar.gz? I've done this before on my local machine (with KDE library files of a different version) so I know something like it could be done. <Rant> And will you all stop saying that I advocate the idea that the distro packagers should stop, or are going to stop, making packages already? I've already clarified *twice* now that I don't believe that this should be the case, and frankly, I'm tired of hearing it stated or insinuated. </Rant> --WorLord

That's better. - not me - 2001-04-14

Including all of KDE's shared libraries with it would reduce the memory requirements from a statically linked KDE. It still wouldn't be an optimal solution, though, because there would be duplicates of nearly every shared library in memory. For example, KDE would come with its own glibc, and the system's glibc would also have to be in memory at the same time for all other applications. It might be worth looking into, though. Certainly it's much better than a statically linked KDE. Still, though, I think that KDE would be better off letting people download their distribution's packages, and staying out of the binary distribution business. It reduces the support load that KDE must bear, and it provides a smaller download, better performance, and better distro integration for the end user.

Re: Here is the reality... - CyberCzar - 2001-04-12

As Underthumb so prophetically said in his initial post by quoting the Goals of the KDE Project HTML page: "...the lack of an easy to use contemporary desktop environment for UNIX has prevented UNIX from finding its way onto the desktops of the typical computer user 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 average computer user." Ok, call me blind but nowhere does this mention LINUX or LINUX distributions. As my Aunt Mary used to say, "Build a bridge and get over it!" Warlord and Undethumb can quit whining right now, before I send a pound of cheese to both of your houses.

Um, you _are_ blind... - WorLord - 2001-04-12

...Either that, or you didn't read the *entirety* of the KDE general overview, and dealt with Underthumb's quote completely out-of-context as a result. You wrote, "Ok, call me blind but nowhere does this mention LINUX or LINUX distributions." From http://www.kde.org/whatiskde/index.html : "Without UNIX the internet would not be. But UNIX did not address the needs of the average computer user. This fact is particularly unfortunate since a number of implementations of UNIX ( Linux, FreeBSD, NetBSD etc.) are freely available on the internet. All of which are of exceptional quality and stability." The bottom line analysis here is that the KDE general overview is clearly grouping *all* of the Unix implementations together when they use the word "UNIX," and Linux was even specifically listed in this grouping. So yes, it does, in fact, quite clearly mention Linux. Specifically, even. "Warlord and Undethumb can quit whining right now, before I send a pound of cheese to both of your houses." Typical. Unable to address the issues at hand, you reduce valid points to "whining". --WorLord

A very big misunderstanding. (was: Here is...) - Karl-Heinz Zimmer - 2001-04-12

On Wednesday April 11, @02:44PM, WorLord wrote: > The reality here is that Underthumb is, > without a doubt, 100% correct. I am sorry but things are not always what they seem. There are fundamental errors in that theory(!) of KDE developers ignoring their own goals by not taking enough care for the for existence and quality of binary packages! Please let me explain what I mean. 1st: Right, since in the KDE project there >>are the GOALS that KDE is going for... an "easy to use" or "user-friendly" desktop<< it is quite reasonable to think: "OF COURSE they MUST look for ways to have _good_ binary packages available _in_time_." 2nd: Seeing KDE developers planing to make it more visible that the Distro-Makers are the ones who actually take care for the binary packages (by changing the policy so that KDE would only publish pointers to the Distro-Makers servers and the users would get the packages *there*) /might/ lead to the conclusion that these KDE developers DO NOT MIND IF the users will get good binary packages in time. 3rd: Comparing this conclusion ("They don't mind...") to their goals (user-friendly...) can produce an imagination of KDE developers who do not act according their own goals. The thread shows clearly that this has allready happened: there actually are some people thinking that the way KDE developers act is not nice/not according to their goals/not smart... and so on. Ok, where is the misunderstanding? Very simple! ad 1st: The KDE developers actually *do*look*for* ways to have _good_ binary packages available _in_time_. ad 2nd: The KDE developers actually *do*mind*if* the users will get good binary packages in time. ad 3rd: The KDE developers actually *do*follow* their goals of being user-friendly and easy-to-use. Why this? Didn't we read about them whishing to have the binaries on the Distro-Makers servers? This is right, but this is no Con - it is a Pro argument for my claim! Please take the following into account: * There are lots of Linux Distributions. * The Distro-Makers know best how to build KDE-packages for their respective distribution. * The KDE developers encourage the Distro-Makers to build packages by giving them the sources even *before* the self-compiling :) users will get them. Look at the contrary: What would be the result, * if the KDE developers tried to make the packages themselfes? The result would be: * Packages that do not fit so good into the respective distributions - since the KDE developers don't have all internal information about how the Distro-Maker wants to set up his system... * Packages would not be available in time - since not *all* distributions could be covered by the stressed developers fast enough... * Users would cry! * Distro-Makers would cry! * You, dear WorLord, would cry: "Why do these hackers think they are smarter than the people who constructed Distribution A???" "Why the hell do these hackers not support Distribution B 6.9 but only B 7.0???" "Why do they not HELP THE PEOPLE WHO KNOW HOW to do the packaging job???" "If they arrogantly thinking they must do it themselfes, than I expect them to do the job PERFECTLY!!!" and so on... I am sure, this is not the scenario you would like most! You surely appreciate to get _good_ binaryp ackages and to get them _in_time_. So the solution is extremely simple: Just act as any Linux User who does not want to build her/his system from crash: Choose the distro that fits your needs! The one where you see that the Makers support KDE by providing you with good binary packages - in time! Every Linux-Distro user expects to get a mail each time the company making the distribution has fixed a security hole and the new RPMs (or whatever they use) are prepared. It *should* be quite normal to find a mail telling you nicely that "YES, we have the KDE binaries in place TODAY!" soon after (or even the evening before?) the official announcement of the next KDE release is made. This is reality: * The Distro-Makers are the ones who CAN do this job best - because of their internal knowledge. * The Distro-Makers are the one who SHOULD take this job seriously - because of their internal knowledge. Where does this knowledge come from? It results from them making things THEIR WAY - to be better than (or at least diifferent from) the competition. This 'making things different' produces both a CHANCE and a RESPONSIBILITY for the distro makers: + The big chance to be very good and to have many friends loving your special concepts... + The responsibility to take care for things like having important packages updates fast enough. The result would be: a) KDE users will be happy. b) KDE developers will help the distro makers understand some KDE details (in case they will need such knowledge in order to adjust the KDE to their system...). c) Distro makers would compete not only on the field of having the best ideas but also on the field of being the first to provide their users with a KDE update. All of this is not theory but the way it is right now and I am sure: this is the way is *must* be in order to have good packages and to have them in time! (Oops, did I say this before?) :-)) There is only *one* way to make things even better: Tell your Distro-Maker that you die hard WANT the next KDE update and you want it SOON! The KDE developers *do* their job: encouraging the distro makers to take KDE package updates even more seriously is the best they could do! Best greetings, Karl-Heinz (and please forgive my bad english!) -- Karl-Heinz Zimmer * Foehren * Germany

You are correct - there IS a big misunderstanding - WorLord - 2001-04-12

...and you're making it. "binary packages" That phrase IS the whole misunderstanding. I said I thought it best for KDE to produce working _binaries_, not working binary _packages_. The two concepts are radically different, although most people here seem to erroneously take them as synonymous. Since those facts pretty much render most of your post irrelevent, see my discourse with no_one for the latest and greatest details. --WorLord

Re: You are correct - there IS a big misunderstanding - Karl-Heinz Zimmer - 2001-04-14

Worolrd wrote: > "binary packages" > That phrase IS the whole misunderstanding. > I said I thought it best for KDE to produce > working _binaries_, not working binary > _packages_. I am sorry, but this comment gives me the idea that you never read Maximum RPM or something like that. What binaries do you want? Statically linked ones of enormous size? Or do you want packages that could be plugged into your distribution - taking all dependencies and side-effects into account automatically. The 'normal user' wants a package made by people knowing the Distro, not a plain _binary_ - so forget about that! * The KDE developers produce programs of high quality. * The Distro Makers should produce packages by taking the sources, building the programs and libs and building the packages - that's the only thing that makes sense!

Maximum RPM? - WorLord - 2001-04-19

"I am sorry, but this comment gives me the idea that you never read Maximum RPM or something like that." What is "Maximum RPM"? A Magazine? You're using a magazine to back an argument? "What binaries do you want? Statically linked ones of enormous size?" See my other post. I answered this one already. "Or do you want packages that could be plugged into your distribution - taking all dependencies and side-effects into account automatically." With all due respect, sir, I've yet to see more then a handful of Distribution Packages that work well and proper with the _Distribution they were created for_, much less with anything else. And I've seen more then my share of "dependencies" that - well, weren't. Point being, I don't think the KDE people could do anything worse then what's being done now. "The 'normal user' wants a package made by people knowing the Distro, not a plain _binary_ - so forget about that!" You have no idea what a "normal user" is, or what they want - and this sentence proves it. ;-) A normal user wants to download a file, run it, and have it work. That's it, and thats all. The normal user doesn't know or bloody well CARE who made the package, or if it "knows" the distro. A normal user doesn't even know how to properly define "Linux Distribution." They say things like "I just bought Linux 7.1, can you help me set it up?" Now normally, I'd be on your side in the situation... but then again, we're talking about people who've made it a goal to create a desktop environment FOR the "normal user" - the ones who don't really know what they are doing. They simply want a download, click, and run experience (or else more of them would be running linux instead of MacOS or Windows). Most, if not all of them, could care LESS if copies of files get installed to different places on the hard drive, as long as it *works*. And that's pretty much the bottom line. --WorLord

Re: Maximum RPM? - not me - 2001-04-20

"The normal user doesn't know or bloody well CARE who made the package, or if it "knows" the distro." The normal user might not know who made the package, but they certainly will CARE when none of their programs show up in the K menu, or when they find out they can't configure anything except KDE itself from the Control Center, or when Konqueror takes twice as long to start up because they're out of memory from the extra sets of libraries they have to load to run their binary-distributed KDE, or when KDE doesn't automatically start when they boot their computer. These are the sorts of problems that distro-created packages solve. Distros integrate their programs into their own customized menus, which would not show up in an "official" KDE binary package. Distros add icons to the KDE desktop to access their value-added features such as X configurators, hardware detection and setup utilities, etc. Distros link KDE against the proper libraries so that the "shared" aspect of the libraries can work as it was intended to and reduce memory usage. Distros add KDM to their startup scripts so that KDE is started automatically. None of these features would be provided by an official KDE binary distribution. A binary-distributed KDE would be an isolated KDE - totally seperate from the distribution, and much worse off because of it. In short, users may not care who made the package, but they DO care about how well the package integrates with the distribution. Official KDE binary packages could not provide that integration. You allege that distro-provided packages do not work well. Which packages are you referring to? I'm curious. Anyway, I think that in 6 months or so, dependency conflicts will be much less of a problem. It seems that everyone and their brother is rushing to implement apt-get like functionality in their distribution (and for good reason!). RedHat has up2date, Ximian (or is it Eazel?) has Red Carpet, Mandrake has DrakRPM and urpmi. With the introduction of these automated package tools, upgrading will suddenly become a whole heck of a lot easier, and more foolproof. rpm --force could become a thing of the past, solving many package conflicts before they begin. Personally, though, I can't understand why they don't all just switch to Debian ;-)

Distro Integration issues - WorLord - 2001-04-20

"The normal user might not know who made the package, but they certainly will CARE when none of their programs show up in the K menu," As far as I'm aware, only MD 7.x integrates the K-Menu with the generic X-based menu system. So anyone not using mandrake is used to menus *not* being integrated in different X shells/WMs. "or when they find out they can't configure anything except KDE itself from the Control Center," I'm using packages for my distribution, and Control Center STILL only configures KDE. That's because the KDE CC was only written _to_ configure KDE I am unable to find any documentation stating that it's built to configure anything else. "or when Konqueror takes twice as long to start up because they're out of memory from the extra sets of libraries they have to load to run their binary-distributed KDE" Why does it have to be extra? QT and KDElib isn't going to load *twice*, you know it's just that the "isolated" libraries will load, instead of any other copy of the file that may be lurking in the system's "/usr/lib" directory. "or when KDE doesn't automatically start when they boot their computer." This was discussed already, wasn't it? "These are the sorts of problems that distro-created packages solve." And for the *last frickin' time*, I will - for the record - state that I ***never once implied or directly stated that Distro packagers should or would stop pumping out their own RPM/DEB/tar.gz packages***. I'm really trying to stay calm about this, but how many goddamn times do I have to write this before someone will actually read and understand it? I'm up to three different times, by my count and unless I miss my guess, I've already cleared this up with you, specifically, at least once. That the individual distro packagers should stop what they're doing and let KDE people take over completely is _just not what I'm suggesting_. IT'S NOT WHAT I'M SUGGESTING. Okay? Jeeeez. "You allege that distro-provided packages do not work well. Which packages are you referring to?" I'm referring to the (sometimes) nightmare that is the current state of RPMs in general. 9/10 times, they claim to need a file or are missing a library that is already installed, or in plain sight, or simply not required for functionality. Several times, in fact, certain few RPMs (which will remain nameless) were claiming dependency on a library that was actually contained in the PRM itself - effectively, an RPM that was refusing to install because it was dependent upon ITSELF! Talk about doing a double-take (Slightly off-topic, and from my own personal experience now, MandrakeUpdate was really working well to relieve this headache. I say "was" because somewhere along the line the packagers just stopped releasing 'new software release' packages for 7.2, and stuck to security updates only. And even *that* was okay for a while, until the Cooker switched over to glibc2.2, making any and all cooker files totally incompatible with 7.2 unless you REALLY, REALLY knew what you were doing. So - practically speaking now - the one good tool that made RPMs a snap to use made itself unworkable after only about 3-4 months of its official release.) "Personally, though, I can't understand why they don't all just switch to Debian ;-)" Because, for the most part (IMO now) Debian is just a pain in the butt to install, even for a seasoned veteran. I don't imply that it's _difficult_, mind you just a PITA and a chore to do. I'd love to use Debian myself, but I refuse to do so in an age where there are so many other good distributions that *don't* require hand-holding all throughout the install process. ;-) And I must admit that the Pentium Optimizations of Mandrake are the main reason I stick with it. Does Debian do this? --WorLord

Re: Distro Integration issues - not me - 2001-04-21

"As far as I'm aware, only MD 7.x integrates the K-Menu with the generic X-based menu system." Debian does too (though they don't replace the entire menu - they make their own submenu, which is nice). I don't know about RedHat or anyone else, but my impression was that most distros added at least _something_ to the K menu. I know they add stuff to the desktop. Mandrake is a poster-child for this, as they entirely replace the K menu with their own. "Control Center STILL only configures KDE." Yes, but distros include their own control centers, which are integrated into the KDE menus or desktop, and would be inaccessable from your universal KDE. (except by the command line, however we're talking about so-called "normal users" here who want everything to be easy and GUI). When I said that the users would be frustrated that they could only configure KDE, I meant that they would only be able to find KDE's control center and wouldn't see their distro's control center. BTW, some distros actually do add modules to KControl to configure the distro (Caldera). IMHO they should all do this, especially Mandrake (what's up with all the GTK based config tools inside a default KDE/QT desktop?!). "QT and KDElib isn't going to load *twice*" The KDE libraries won't, but if the user has *any* package from their distro that uses QT, that will require a seperate version of QT to load and QT *will* be loaded twice. I wasn't talking about QT, though, I was talking about glibc and libstdc++ and all the other shared system libraries that *will* be loaded twice because KDE uses a different version than the entire rest of the system. This was discussed up in our other thread. "This was discussed already, wasn't it?" I'm sorry, I don't see that discussion. I don't see how universal packages could solve that problem. "IT'S NOT WHAT I'M SUGGESTING." DID I SAY THAT WAS WHAT YOU WERE SUGGESTING? NO! Jeez yourself. I was SAYING that these problems are solved by distro-created packages. My point was that if distro-created packages are better for the reasons I described, there is no reason for KDE to put out their own inferior packages. "9/10 times" Hyperbole. If RPM was really THAT bad, no one would use it. Anyway, let me guess: You're using Cooker packages. There's a _reason_ they're in Cooker. If you really care that much about not having RPM headaches, you simply can't use Cooker RPMs. Don't use beta RPMs and then go around complaining to everyone when they don't work correctly. "Debian is just a pain in the butt to install" Got to agree with you there, the install is hard. I had a lot of headaches because I was trying to do a network install, but my network card wasn't supported, so I had to get the kernel headers for Debian's kernel onto my other distro and compile the new kernel module driver there, then insert it manually into the running kernel during the install from a text console. But it's sooooooo much easier to maintain afterwards! Anyway, the new version of Debian due out this year will include a nice graphical installer (plus kernel 2.4.X, which would have solved my networking problem). Also, you could give Progeny Debian a try. They supposedly have a really nice and easy graphical install, available now.

Re: Distro Integration issues - WorLord - 2001-04-26

"When I said that the users would be frustrated that they could only configure KDE, I meant that they would only be able to find KDE's control center and wouldn't see their distro's control center." Oh. Well, *that* is certainly out of the scope of the KDE project. "IMHO they should all do this, especially Mandrake (what's up with all the GTK based config tools inside a default KDE/QT desktop?!)." Boy, if that's not the best question to ask, I don't know what is. "I wasn't talking about QT, though, I was talking about glibc and libstdc++" Pardon my ignorance, but why were you talking about glibc and libstdc++? As far as I'm aware, *everyone* who uses Linux has these, so why would KDE need to supply it? That wouldn't be a KDE binary, that would be a whole new system (and, as such, way out of the scope of what I was talking about). "DID I SAY THAT WAS WHAT YOU WERE SUGGESTING? NO!" Then why the heck do you keep bringing them up?? My suggestion that KDE release their own binary has NOTHING to do with distribution packages/packagers. Nothing whatsoever. I'm only concerned that KDE release *some* kind of binary package, because I think that foisting binary releases off on distros is an irresponsible thing for KDE to do (in light of it's stated goals, and everything). What the distributions do outside of (or instead of) that generic binary is their own story, and not at all related to the idea that KDE should release one. "I was SAYING that these problems are solved by distro-created packages. My point was that if distro-created packages are better for the reasons I described, there is no reason for KDE to put out their own inferior packages." Yes, there is. Their stated goals are the reason they should at least release something. "You're using Cooker packages." Bad guess. To be honest, I don't seem to have very many problems with Cooker. More often then not, my problems come from the software homepages themselves. If I want to d/l something, I typically try to go to its page to see the latest information and d/l the latest binaries direct from the writer. Such RPM packages for Mandrake have proven to be more of a trial then anything else. "But it's sooooooo much easier to maintain afterwards!" Because they wait two years between updates? <grin> Just kidding. which would have solved my networking problem). Also, you could give Progeny Debian a try. They supposedly have a really nice and easy graphical install, available now. One question: do they use Pentium Optimizations in their packages? That's pretty much the Main Reason I use Mandrake. I don't know of any other distro that does this, and I really do see a difference between i386 and i586 or i686 packages 'specially on something as large as the entirety of KDE. --WorLord

Re: Distro Integration issues - not me - 2001-04-26

>Well, *that* is certainly out of the scope of the KDE project. Yes! Its up to the distros to supply packages for their control centers. Its up to the distros to supply KDE packages that integrate nicely and display icons for their control centers and all that. It is NOT up to KDE to provide inferior packages when there already are superior distro packages out there. It would only be confusing to new users of KDE. Which packages should they get? Some would end up going for the "official" packages and would end up with bad performance and no distro integration. >*everyone* who uses Linux has these, so why would KDE need to supply it? As we discussed earlier, but you seem to have forgotten, a universal binary KDE would have to include its own versions of these libraries. Thus KDE would load its own version, and share it between KDE components, and all distro programs would share a different version. Therefore there would be 2 libraries loaded in memory for every library that KDE uses, doubling library memory usage. Intstant bloat. >Then why the heck do you keep bringing them up?? Because I'm showing that any KDE universal binaries would be inherently inferior to distro packages and thus it would be a *BAD* thing for KDE to put out these inferior packages. It would confuse and frustrate users because they would get bad performance and bad distro integration - they would switch to GNOME or go back to Windows or something. >I think that foisting binary releases off on distros is an irresponsible thing for KDE to do (in light of it's stated goals, and everything). I think would be irresponsible and against KDE's goals to put out inferior packages. KDE wants to provide the best desktop possible. >Yes, there is. Their stated goals are the reason they should at least release something. I don't think that some page of several-year-old stated goals archived somewhere on the KDE website should suddenly require KDE to put out inferior binary packages. >One question: do they use Pentium Optimizations in their packages? Unfortunately, no. Ah well, they can't have everything, I guess. I might try Mandrake again now that 8.0 is out. I'm happy with Debian, but I do happen to have a spare partition lying around, and I like nifty control panels and Pentium optimizations...

Re: Distro Integration issues - WorLord - 2001-04-26

"It is NOT up to KDE to provide inferior packages when there already are superior distro packages out there." It is up to KDE to provide some kind of working binary packages, because that is the very _first_ step towards making the desktop easier. There is just no logical way to talk around this fact. They want to make the desktop experience easier, they need to be sure that there is at least one easy way for a _standard user_ to get KDE (and JUST KDE) working on the system. And personally, I think your idea of an "inferior" binary package is warped. Tying in to a distro is a *nicety*, not a *requirement*. Are all Red Hat configuration tools "bad" or "inferior" because their RPMs don't tie into DrakConf's control panel? Should I fire off a flame letter to anyone who releases a binary RPM for Mandrake that doesn't put a "shortcut" in the DrakMenu system? Of course not. DrakConf tools are a nicety provided to Mandrake users, as is the DrakMenu System. These are by no means some kind of a cross-platform Linux requirement. The only "inferior" binary I can think of is one that _doesn't work_, or only works halfway (half the supplied KDE apps don't function properly, for example). A binary KDE package that works, but doesn't tie in to a distro is simply a 3rd party software release... like most out there that aren't specifically packaged for a distro (StarOffice's and Mozilla's packages come to mind most readily, and there are many others). "Some would end up going for the "official" packages and would end up with bad performance and no distro integration." Pure unfounded speculation, on both counts. "As we discussed earlier, but you seem to have forgotten, a universal binary KDE would have to include its own versions of these libraries." Uh, we did NOT discuss core libraries like Glibc or libstdc++. We discussed libraries that were *Core Only To KDE's Functionality*, like QT or LibKDECore. Look at Mozilla and StarOffice - complete binaries, free of dependencies, are available for each different Version of Glibc (there aren't that many), and include all files required to run each package. To say that Glibc needs to be included is to exaggerate things beyond the point of usefulness. Are you purposefully being dense to prove a point, or have you just not seen other software packages provide binaries similar to what I'm suggesting? Because what I'm suggesting is certainly not a new or flawed idea. "It would confuse and frustrate users because they would get bad performance and bad distro integration - they would switch to GNOME or go back to Windows or something." Well, see, that's kind of why I'm fired up about this in the first place... with the attitude that KDE has displayed in this article (which boils down to "If you don't like or are unable to compile our source code release, then bugger off or contact your distribution's people," to put in in a nutshell) people will definitely switch to GNOME or back to Windows left and right. And they'll do this because it's either A) Such a pain in the ass to install KDE from source, or B) KDE binaries for their specific distribution aren't available yet. GNOME may be technically inferior, bloated, buggy, and almost always technically inferior to KDE (especially 1.4, Red Carpet, and Nautilus, IMO) - but at least one can type a single command and have a graphical installer not ONLY walk them through the process of installing, but *also* find them the fastest server and D/L all packages and dependencies for them whilst they stare at pretty pictures. KDE is, IMO, the best Unix users have as far as a terrific desktop shell system. But before the average user can form that opinion, they have to get in on their system first - which is exactly where KDE stops. It's a damn shame to see them forget their values, point fingers, and abandon their target audience (regular users) in all the areas where they are really needed the most. GNOME may not be the best answer, but at least it can be installed by someone who really wants the stability of Linux, but doesn't know what an RPM or header file is. "I think would be irresponsible and against KDE's goals to put out inferior packages. KDE wants to provide the best desktop possible." Provided you pass all the necessary gear-head requirements to compile it from source or wait for packages, that is. Hypocrisy is, at it's simplest, saying one thing and doing another. Kind of like saying you want people to have the best desktop possible, and then doing nothing to facilitate the process of attaining and installing it. ">Yes, there is. Their stated goals are the reason they should at least release something. I don't think that some page of several-year-old stated goals archived somewhere on the KDE website should suddenly require KDE to put out inferior binary packages." Because it's "several years old" does not change the fact that such a document is essentially the Mission Statement for KDE - it's whole reason for existing. (And if it is out of date, then why not revise it and change the motive line to better reflect the KDE project's current attitude? I've suggested that point twice now, and it essentially went ignored.) And to say it's "buried" are the words of someone who doesn't really surf the KDE site very often - the "What is KDE" link (from which the quoted material was taken) is pretty much the very first link available in the left-hand NavBar. And I'd argue that "inferior" is a warped way to look at the proposed package scheme, but since I argued this already, I'll just say "see above". ">One question: do they use Pentium Optimizations in their packages? Unfortunately, no. Ah well, they can't have everything, I guess. I might try Mandrake again now that 8.0 is out. I'm happy with Debian, but I do happen to have a spare partition lying around, and I like nifty control panels and Pentium optimizations..." MD 8.0 is supposed to be uber-excellent - I haven't seen the alt.os.linux-mandrake NG have so many positive postings on one of their new releases since MD 6.2. Naturally, I'm looking forward to it, although I'm quite happy with 7.2 (but damn, I want the new kernel). Apt-Get is about the only thing about Debian I envy, and with MandrakeUpdate (hopefully it'll stay useful longer this time), I don't really miss it that much. --WorLord (wonder if CheapBytes has it yet...)

Re: Distro Integration issues - not me - 2001-04-27

>they need to be sure that there is at least one easy way for a _standard user_ to get KDE (and JUST KDE) working on the system. There are KDE packages available for every distro I'm aware of, and surely any distro that a _standard user_ would be using. That _is_ one way for users to get KDE on their system, and as I have been arguing, it is a better way*. Look at it this way. A user would have only four reasons to want your binary KDE packages: 1. Their disto doesn't provide KDE packages. I don't know of any distro that would be used by people who couldn't compile KDE on their own that doesn't have KDE packages available. Heck, I don't know of ANY distro that doesn't offer KDE packages! No one needs binary KDE packages for this reason. 2. Their distro's KDE packages are a couple days late and they want the NEWEST KDE RIGHT NOW!!! This is not really a valid reason. I mean come on, a couple of days is NOT too long to wait for better* packages! 3. Their distro's KDE packages are broken. This is a valid reason to want KDE binaries. However, it hardly ever happens - most problems are due to errors such as rpm --force when it's not really necessary. When it does happen, distros upgrade their packages promptly, as KDE is an important package for them and it is essential that it work properly. 4. They don't know that their distro has KDE packages available. In this case, it is better to direct users to their distro's KDE packages than give them inferior* binaries. There is no other reason for users to want or need official KDE binaries. >Kind of like saying you want people to have the best desktop possible, and then doing nothing to facilitate the process of attaining and installing it. You think the KDE people have done nothing to facilitate the process of attaining and installing KDE?! You're crazy. The KDE people care very much about this - they work with the individual distro packagers closely, and a KDE auto-installer program is in the works. Simply because one guy got fed up with all the newbies asking him to help them with packages that he didn't make and posted this article to the dot doesn't mean that the entire KDE project doesn't care about its users. Simply because the KDE project doesn't see the need to release inferior* binary packages doesn't mean it doesn't care about its users. *You claim that I am just speculating when I state that official KDE binaries would be inferior? You must not have been reading my comments! That is exactly what I have been arguing (and, IMHO, proving) in most of my comments! I have given reasons galore! Let me respond to your latest objections: >Tying in to a distro is a *nicety*, not a *requirement*. It may be a nicety, but it makes distro packages superior. Themeing is a nicety. Heck, all of KDE is a nicety! Do you want to go back to the command line? It's just as capable (and in many cases more capable, once you learn how to use it!) GUIs are just a nicety. I claim they are superior because of their niceties. I claim that distro packages are superior to proposed KDE binary packages because of their niceties. What is wrong with this? Besides, having an icon for a distro control center, auto-updater, etc isn't just a nicety for some people - perhaps even your _standard user_ - because they wouldn't know otherwise how to start it, or even that it exists! >The only "inferior" binary I can think of is one that _doesn't work_, or only works halfway How about one that is bloated and doesn't have as many features as compared to another that's also available? Doesn't that qualify as inferior? >Look at Mozilla and StarOffice - complete binaries, free of dependencies, are available for each different Version of Glibc (there aren't that many), and include all files required to run each package Oh, now KDE has to provide a seperate binary package for every permutation of Glibc and libstdc++ versions that is out there? Give me a break! Now, instead of having one, canonical, easy KDE binary package, you have many, only one of which will work on a given user's system. To tell them apart and tell which one will work on their system, users have to poke around in their system directories looking for library version numbers. I prefer distro packages, of which there are only one set and they always work. If the distro packages are out there, KDE's packaging obligations are fulfilled. OK, I found the page on the KDE site. You seem to be most worried about this part or a part like it: "It is our hope that the combination UNIX/KDE will finally bring the same open, reliable, stable and monopoly free computing to the average computer user that scientist and computing professionals world-wide have enjoyed for years." You seem to be saying that because of this statement KDE has an obligation to see that all users can enjoy an easy way to install and use KDE, without mucking around with source code or obscure command-line interfaces. And here I agree with you. You also seem to be saying that because of this, KDE has an obligation to provide universal binary packages. The second statement does not follow from the first! If there is *already* an easy way for users to install KDE, then KDE has no such obligation. I argue that distro packages are *already* an easy way for users to meet their KDE needs and therefore, KDE's packaging obligations are already met. >MD 8.0 is supposed to be uber-excellent That's über :-)

Ideas and Clarifications - WorLord - 2001-05-03

">they need to be sure that there is at least one easy way for a _standard user_ to get KDE (and JUST KDE) working on the system. There are KDE packages available for every distro I'm aware of, and surely any distro that a _standard user_ would be using. That _is_ one way for users to get KDE on their system, and as I have been arguing, it is a better way*." But it **is NOT KDE making sure** that there is at least one easy way. That is KDE letting the distributions fend for themselves - which, again, is something that is totally contradictory to their stated goals. Just because this perceived "better" way exists doesn't do anything to deter my point. In fact, I argue that this "better" way exists 'cause KDE refuses to be bothered with making an official, proper, and easy way (like they really should.) You don't seem to be understanding where I'm arguing from; I'm arguing from the position of "KDE is saying one thing, and doing another;" I'm NOT arguing from the place of "KDE can do a better job then what's being done currently". Your position, while admittedly more _practical_ then my own, misses the point I'm making entirely. "You think the KDE people have done nothing to facilitate the process of attaining and installing KDE?! You're crazy." Uh, HELLO? What the heck do you think the Dot story that started this mess was all about?? It was pretty much a _direct statement_ to the tune of "we are not responsible for facilitating the process of attaining and installing KDE, so _stop asking_"!!! "Simply because one guy got fed up with all the newbies asking him to help them with packages that he didn't make and posted this article to the dot doesn't mean that the entire KDE project doesn't care about its users." That statement would be true if he weren't speaking on behalf of the entire KDE project problem is, he happened to be speaking on behalf of the entire KDE project! "*You claim that I am just speculating when I state that official KDE binaries would be inferior? You must not have been reading my comments! " This statement is a variation of the "understand/agree" logical fallacy. Just because I find your comments to be purely speculatory doesn't mean I haven't read them it only means that I've read them and found them to be purely speculatory. >Tying in to a distro is a *nicety*, not a *requirement*. "It may be a nicety, but it makes distro packages superior." But "preference" is not spelled s-u-p-e-r-i-o-r. I am skipping other like arguments, because I have the same response. "Themeing is a nicety. Heck, all of KDE is a nicety!" This is a slippery-slope fallacy, and is steering the conversation functionally out of range. "Do you want to go back to the command line?" Now that you mention it, the CL is where I spend most of my time. "Besides, having an icon for a distro control center, auto-updater, etc isn't just a nicety for some people - perhaps even your _standard user_ - because they wouldn't know otherwise how to start it, or even that it exists!" Since you bring that up, I'd like to let you know that your "standard user" doesn't really use the updater tools/control center because it was set up FOR them in most cases. The "standard user" Uses the computer; 99% of them don't update them or change the preferences in the control center. (Of course, my job as a Sysadmin is the only experiential fuel I have for this fire; but the fact that I've been at it for 15 years makes me pretty certain of the truth in my words). "Oh, now KDE has to provide a seperate binary package for every permutation of Glibc and libstdc++ versions that is out there? Give me a break!" I find it humerous how you can complain about something that at least two _very_ popular pieces of software do already. This is a standard practice I'm suggesting, not a radical one. "Now, instead of having one, canonical, easy KDE binary package, you have many, only one of which will work on a given user's system. To tell them apart and tell which one will work on their system, users have to poke around in their system directories looking for library version numbers." Are you being dense on purpose? A simply-designed web site (that can even go as far as asking what distribution the user has) would point to the proper download. You really are making this sound so much harder then it really is. OK, I found the page on the KDE site. You seem to be most worried about this part or a part like it: "It is our hope that the combination UNIX/KDE will finally bring the same open, Actually, no. Refer to my earlier posts (and Underthumb's as well) to find the specifically quoted bits I'm talking about. "see that all users can enjoy an easy way to install and use KDE, without mucking around with source code or obscure command-line interfaces. And here I agree with you. You also seem to be saying that because of this, KDE has an obligation to provide universal binary packages. The second statement does not follow from the first!" I suggested what I suggested as a possible solution; not the final one. The bottom line of my statement is that KDE is, by their OWN rules, responsible for providing SOMETHING other then source code and that's it (which is pretty much what this article is about!) There are better ways being suggested, and even worked on. I welcome better ideas, and actually prefer the KDE Installer - that idea totally trumps my own. >MD 8.0 is supposed to be uber-excellent That's über :-) Oh. Sorry. ;-) --WorLord

Re: Ideas and Clarifications - not me - 2001-05-07

"You don't seem to be understanding where I'm arguing from" You're right. I don't understand how you can argue that KDE should provide packages that aren't as good simply because they state they want to make an easy-to-use desktop. My argument is that if good distro packages are in fact out there then KDE's obligation to make the installation easy (an obligation that comes from their stated goals) is *already fulfilled*. It doesn't matter that KDE itself hasn't actually made the installation easy, KDE didn't state in their goals that they had to do everything themselves. If there weren't distro packages out there, or if KDE could do better than distro packages, then of course it would be a whole different story. "[this article] was pretty much a _direct statement_ to the tune of "we are not responsible for facilitating the process of attaining and installing KDE, so _stop asking_"!!!" KDE doesn't do much to help users with specific distro packages, that is true. However, that doens't mean that they have done nothing to help users obtain and install KDE! They work with distro packagers and help them. And, as long as _support_ for distro packages exists, then KDE has no obligation to support distro packages. It's the same argument as my other one. This article was about misdirected complaints: People are complaining to KDE about packages that were made by distros. They can and should contact their distros instead. >"Simply because one guy got fed up with all the newbies asking him to help them with packages that he didn't make and posted this article to the dot doesn't mean that the entire KDE project doesn't care about its users." "That statement would be true if he weren't speaking on behalf of the entire KDE project problem is, he happened to be speaking on behalf of the entire KDE project!" The statement is still true. I would argue that this article doesn't even mean that the author doesn't care about KDE's users. He simply wants them to direct complaints to the correct place. Just because that place is not technically part of KDE (though the packagers are closely related) doesn't mean that he doesn't care. "This statement is a variation of the "understand/agree" logical fallacy. Just because I find your comments to be purely speculatory doesn't mean I haven't read them it only means that I've read them and found them to be purely speculatory." You can't call my arguments speculatory because I have provided reasons. You can call them wrong (and you have), but that's different. "But "preference" is not spelled s-u-p-e-r-i-o-r." Huh? If you have a preference for something, don't you think its better? I prefer Windows over Linux because I think its better. I prefer distro packages over proposed KDE binary packages because I think they are better. "This is a slippery-slope fallacy" It is not an out-of-line slippery-slope fallacy. I was merely giving examples of the fact that niceties make programs easier to use and easier-to-use programs are better. You were arguing that since you thought distro integration was a nicety, it wasn't required. I was arguing that "niceties" such as integration make KDE easier to use and therefore make distro packages better, which supported my point. "your "standard user" doesn't really use the updater tools/control center because it was set up FOR them in most cases." They may not use it on a regular basis, but there _will_ come a time when they wish to use it for _something_. What if they buy a new printer or something and want to set it up? I agree that a "standard user" wouldn't use the control panel on a regular basis, but there would definitely be a few times when they would want it to be there. "The bottom line of my statement is that KDE is, by their OWN rules, responsible for providing SOMETHING other then source code and that's it" No, KDE is responsible for *seeing that* something other than source code is provided. They *do* see that something other than source code is provided, therefore their responsibility in this case is fulfulled. It does not matter that the distro packagers aren't technically part of the KDE project. Their product is easy-to-use KDE binary packages for everyone. Now, if KDE could do *better* than disto packages, then it *would* be their responsibility to do so. As you point out, the KDE installer project is a good way to improve on distro packages.

Re: Maximum RPM? - Denis - 2004-03-16

Hey, does anybody want to listen to me, user? I don't want a big mega-super package from KDE, I want a package from my distro. And I want that the Slackware team co-work with KDE team to make good package. If I want a KDE version, which not has been released by Slackware yet (as for now KDE 3.2.1), I will use KDE.SlackBuild script which will build whole KDE. I just will need to launch KDE.SlackBuild script - thats all! And I think to make KDE team to make the package for Slackware is very stupid!!!! Why then there should be any distros? I thought that the distro it is the original way to compile, patch and versioning of packages (or maybe some additional programs), so why KDE need to do it for all distros???? Maybe they should also build gcc , sendmail or mozilla for Slackware :))) ? I don't think so, it is very stuppid, to say so - sorry - no offence. P.S. I can find the site of Slackware very easy, and also can find download section and where the scripts are located, why the users of other distros can't do it do you think? I think, they can. However I would like to have something like Windows Update from Slackware (to build new packages), but I think that I should contact Slackware and not KDE for that.

Re: Maximum RPM? - Denis - 2004-03-16

Oh, forgot to say. Why you wrote maximum RPM??? I wont Maximum TGZ!!! :))) Or I want Maximum deb!! or Gentoo, I don't know :)) To think the KDE should do them all it is absurd, anyway I never will use it, and will wait for kde in tgz format from Slackware or launch KDE.SlackBuild if I will loose my patience :) P.S. You should say "Thank you" for KDE team for this bueatifull desktop, if they leave it - there will be only GNOME - oh, no - I'm scared :))

Re: Here is the reality... - Tim - 2001-04-19

Buy Windows. I don't know what you want. Open Source means that whoever wants to contribute can do so. It's the way the enormous amount of work and time is shared. Normally the people working on such a complex project can't know or even do _everything_. _Think_ a minute: KDE is the best desktop, and it runs under _several_ environments, and they are all different. You pay nothing for this awesome result. So, what do you want? If I gave you one Dollar ore one Euro, for free, and you say: "There's one cent missing!", then I think: "Dem fehlt aber mehr als ein Pfennig an der Mark" (=there's much more missing than one cent), as people say in Germany. Good luck. Tim P.S.: To all who contribute to KDE: GREAT WORK!!! P.P.S.: Don't get me wrong, it is okay, when you say there is a thing worth thinking about. But what you say and especially the way you do it lets me know you are an egoist. Switch on the tv and eat some potatoe chips. P.P.P.S: A few days are a very short time to build the packages. If you can make it faster, _then do so_. But if you can't wait and want to be on the bleeding edge you _can_ get the sources. Daily. It's not too difficult.

Re: Here is the reality... - WorLord - 2001-04-19

"Buy Windows." It's not about me, it's about the average user. I'm already running KDE 2.1.1 (with AA support compiled in, even), so I'm obviously not the one who would be having problems installing anything. Making it about me when it clearly isn't is simply an artful (yet clichéd) way to dodge the issue. "I don't know what you want. Open Source means that whoever wants to contribute can do so." It's not about Open Source in general, it's about the KDE desktop and it's *>_Stated Goals_<*. Confusing the two is simply an artful (yet clichéd) way to dodge the issue. "_Think_ a minute: KDE is the best desktop, and it runs under _several_ environments, and they are all different. You pay nothing for this awesome result. So, what do you want? It's not about money, it's about integrity. I don't care if its free or if it costs a million bucks: if one says that one is going to do something, then I expect that person to live up to his/her word without half-assing or ignoring an integral part of the process. That's what I want. And making it about money instead of integrity is simply an artful (yet clichéd) way to dodge the issue. If I gave you one Dollar ore one Euro, for free, and you say: 'There's one cent missing!', then I think: "Dem fehlt aber mehr als ein Pfennig an der Mark" (=there's much more missing than one cent), as people say in Germany. It's not about giving gifts, it's about being true to your word. There is a difference between 1)simply giving something away, or 2) SAYING you're going to give one thing away and then giving another (noticeably lesser) contribution. The first makes you generous. The second makes you a generous liar. Making it about generosity instead of honesty is simply an artful (yet clichéd) way to dodge the issue. *shrug* Of course, no one has addressed the idea of simply changing the stated goals of the KDE project, which would be another equally good (and considerably easier) solution to this whole issue. P.S.: To all who contribute to KDE: GREAT WORK!!! Seconded, yet again. P.P.S.: Don't get me wrong, it is okay, when you say there is a thing worth thinking about. Hollow words, considering the less-then-receptive responses I've gotten... but thanks for at least acknowledging the concept. But what you say and especially the way you do it lets me know you are an egoist. Oh, now wait just a damned minute, sir. Throughout the ENTIRETY of your reply, you've consistently twisted the entire issue to reflect upon me instead of looking at where it's supposed to be targeted (normal users and the stated goals vs. the actual results and actions of the KDE project). And I've pointed out where you've done this, in a point-by-point fashion. How can you screw things up so utterly and completely, and then accuse ME - with a straight face, no less - of being the Egoist in this situation? If you want to know what an Egoist looks like, I strongly recommend that you find the neares mirror and take a good, looong look. (And all I've done here is tell the truth in the easiest most direct, no-nonsense way possible. The "way I do it" is a non-issue, as the decision to take things personally (or not) is entirely yours, and yours *alone*. If you want to actually discuss the points I've brought up, then fine; but I'm not going to waste my time going off-topic and discussing how these concepts make you feel.) Switch on the tv and eat some potatoe chips. TV bores me. I'd much rather be finishing up Clive Barker's _Undying_. But you're right on the Potato chips thing. --WorLord

Re: KDE Package Policy Explained - Peter Kruse - 2001-04-11

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

Re: KDE Package Policy Explained - Kevin Puetz - 2001-04-11

however these are not (always) the same debian dirs used to generate the official debian packages :-) There are RPM spec files in there too. They are sample packaging frameworks, to give distributions somewhere to start. It's still up the the distributions to do final polishing for their specific arrangements.

Re: KDE Package Policy Explained - Henry Stanaland - 2001-04-11

Pray the Lord that RedCarpet or Eazel get their package upgrading stuff working so that we won't have to worry about this anymore!

L.S.D : Slightly off topic, but not that much... - Count Zero - 2001-04-11

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.

Re: L.S.D : Slightly off topic, but not that much... - Ingo Klöcker - 2001-04-12

Count Zero wrote: All distros will all have the same gcc version, the same glibc, the same package managment system etc etc. Unfortunately that's only true if all users are forced to upgrade their whole distribution everytime a new version of KDE is released. And I don't think that this is desirable. For example there are KDE 2.1.1 binary packages for the last four SuSE distributions (6.3, 6.4, 7.0 and 7.1). Of course these different distributions don't include the same version of glibc. Even if there is a LSD you can never assume that all versions of the LSD include the same versions of all libraries. Some LSDs will have older libraries and some will have newer ones. Therefore it will never be possible to just make one binary package for one LSD. You will always have to make packages for LSD 1.0, 1.1, 1.2, 2.0 and so on and so forth. Regards, Ingo

Re: L.S.D : Slightly off topic, but not that much... - Carbon - 2001-04-17

Definetly true. Almost all the problems I have seen in Linux are the result of distribution companies mucking up what the hackers got right. Mandrake, RedHat, SuSE, Slackware, and others have all done this. Fragmentation is bad, it isn't helping BSD, and it won't help linux. P.S. $0.2 is 20 cents, not 2 cents :)

Re: L.S.D : Slightly off topic, but not that much... - Clint Anderson - 2001-11-24

As much as I enjoy LSD, it does happen to be illegal. On another note, I sort of agree with this post but then there is Slackware, which is basically a straight-out-of-the-box linux distro, as close to an 'LSD' as you can get without being a complex molecule.

Re: KDE Package Policy Explained - Joseph Nicholson - 2001-04-11

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

Re: KDE Package Policy Explained - ne... - 2001-04-11

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.

Re: KDE Package Policy Explained - Bruce Jensen - 2001-04-11

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

Re: KDE Package Policy Explained - APW - 2001-04-12

Bruce, You raise some good points, but I must admit that I max out at building either KDE or the incomprehensible GNOME because of the multitude of packages. It's just a big pain in the ass to compile because of the handholding that you have to do to compile and install. But, OTOH, I've downloaded and compiled XFree86 (comparable in source size) because it contains one configure and one make file. It takes time, but it's a straightforward compile and install -- just like every other compile that I bother to do. I've seen recently that a global make script is in the works. After that's reasonably stable, you're absolutely right -- RPMs won't matter. Today for me personally, they do matter. Cheers, APW

Re: KDE Package Policy Explained - Thorsten Schnebeck - 2001-04-12

Ok, lets start a new "culture" of self-compiling ;-) Here is my compile-from-cvs-script: I call it "makelib". You can easily change it to a "makebase", "makegraphics" ... I am far away form being a script-god. If you want to use this script, you have to change it according to your own system settings. <WARNING: This can trash your current KDE installation. "make install" happens as user "root" (asked for password)> (There are maybe some unmotivated line breaks caused by the HTML-formating) USE IT AT OWN RISK! ;-) #!/bin/bash ########### User Options ################ PACKAGE=kdelibs DOWNLOAD_DIR=/opt/kde2/progs CONFIGURE_OPTS="--host=i586-pc-linux-gnu --prefix=/opt/kde2 --disable-debug --with-ssl-dir=/usr/local/ssl" MAKE_OPTS="" CVSROOT=":pserver:anonymous@finwal03.tu-graz.ac.at:/cvs" CVS_OPTS="-r KDE_2_1_1_RELEASE" ######################################### export CVSROOT if !(test -e ~/.cvsrc); then echo -e "cvs -z4 -q\ndiff -u3 -p\nupdate -dP\ncheckout -P" > ~/.cvsrc echo "Found no ~/.cvsrc... fixed!" fi cd $DOWNLOAD_DIR if test -e $DOWNLOAD_DIR/$PACKAGE; then MODE=up cd $PACKAGE echo "cleaning old build before update..." make cvs-clean echo "updating $PACKAGE ..." cd .. else MODE=co echo "first check-out of $PACKAGE ..." fi echo -e "\r" > cvs login cvs $MODE $CVS_OPTS $PACKAGE echo "*** ready! ***" cd $PACKAGE make -f Makefile.cvs test -w config.cache && rm config.cache if test $MODE = "co"; then ./configure --help echo echo "**************************************" echo "all configure options are shown above." echo "$PACKAGE will be configured by:" echo "./configure $CONFIGURE_OPTS" echo "** CHECK YOUR OPTS **" echo fi ./configure $CONFIGURE_OPTS make $MAKE_OPTS echo "$PACKAGE compiled!" echo -e "#!/bin/bash\ncd $DOWNLOAD_DIR/$PACKAGE\nmake install && ldconfig\n" > /tmp/inst.sh chmod a+x /tmp/inst.sh su -m -l root --command="/tmp/inst.sh" rm /tmp/inst.sh echo "installation of $PACKAGE successfull :-)" exit 0

Re: KDE Package Policy Explained - Jason Hanford-Smith - 2001-04-12

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

Re: KDE Package Policy Explained - Anthony Moulen - 2001-04-19

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.

Re: KDE Package Policy Explained - Anthony Moulen - 2001-04-19

Interesting issue... - Jesse - 2001-04-20

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.

KDE Package Policy Explained