Is RPM Doomed? 691
Ladislav Bodnar writes "This is an opinion piece offering solutions for all the ills of the RPM Package Manager. It has been written with Slashdot in mind - it is a fairly controversial topic and I would like to hear the experiences and views of other users who have tried different package formats and different Linux distributions. The conclusions are pretty straightforward - either the big RPM-based distributions get together and develop a common standard or we will migrate to distributions offering more sophisticated and trouble-free package management. Note: the main server allows a maximum of 100 simultaneous connections. To limit the /. effect, here are two other mirrors: mirror-us and mirror-hu (the second one has larger fonts). Thanks in advance for publishing the story."
standardized locations, etc. (Score:3, Insightful)
I hate to say it, but maybe we need a standardized "registry" idea like in MS Windows? I hate to say it, but they do have a good idea with that.
depends (Score:2, Insightful)
The good thing about RedHat and Mandrake to some extent is that they do good testing on the RPMS on the cds. I figure they don't expect people to install some 3rd party RPM off the net.
There is nothing wrong with RPMs. Only packagers. (Score:5, Insightful)
The author mentions, "On the other hand, have you noticed how hard it is to find Debian ISO images?" Yes, Debian is very upgradable, but that has nothing to do with the percieved shortcomings of the RPM package format.
The RPM format is nearly identical feature-for-feature with Debian's dpkg. RPM's upgradability has nothing to do with technical issues. There are three things that make Debian's package management so much better than RPM-based distributions.
The first is, there are way more distributions based on RPM packages than deb's. It's not suprising that some of them are more incompatible with each other than any debian release has ever been. Sure, there are many more people with hairy backs in the US than there are in Lichtenstein, that doesn't mean that living in the US causes hair to grow on your back. He is inferring causality where it doesn't exist.
Second, APT. APT is what makes debian's package management so smart, not dpkg. And, in fact, this isn't a reason at all. APT now works with RPM packages [tuxfamily.org], and when dependencies are properly configured, it is every bit as good as it is on debian. You can make an APT repository with RedHat's "rawhide" distribution and upgrade daily if you want. You won't have any more upgrade issues than you would running debian unstable. It may break occasionally, but it's when large changes happen. The exact same thing happens on the debian side.
Third, Debian is fanatical about consistency. Most debian packagers manage maybe three or four packages (there are exceptions, of course). When you devote all of your free time to just a few things like that, a lot of attention is payed to details. This is what truly makes Debian's package management so freakin' clean. It has nothing to do with technology, it has everything to do with each maintainer hand-crafting dependencies and build options very carefully.
The thing that pretty much any of the RPM-based distributions is truly missing is the equivalent of the Debian package maintainer guidelines, and a culture that enforces it. If that existed, RedHat would be just as consistent and upgradable as debian.
I use RedHat and I'm careful about what I put on my system, and I never run into upgrade issues. If I'm going to install something that is for a distribution other than mine, I build from .src.rpm's instead of binaries and I *know* it's compatible with my install. Someday, if packagers stop being idiots and using shortcuts, I won't have to. Everything will resolve properly in the huge worldwide-apt-rpm-uber-archive.
Re:Luke, use the source... (Score:3, Insightful)
The main concern is that if I install OpenSSH from source on all 50 of my servers when it comes time to patch it I've got myself a little inconvencience. I would most likely compile it on one machine, tar up the source directory (complete with new binaries) and do a 'make install' on all 50 machines so I don't have to recompile for each box. But this is still going to take me a lot of time.
So therefore we've set some policies in place to make keeping systems up to date and secure easy:
For starters, we've standardized on Mandrake for Linux. This helps a lot because if we have a single rpm to install it will install on all of our servers.
We also mirror the updates locally so that we don't have to worry about slow downloads and we make heavy use of urpmi to automatically grab all the updates, check dependancies, gpg signatures and install them for us.
We don't install from source unless we absolutely have to. Actually, we try not to install any software that doesn't come with Mandrake but obviously this isn't always possible. In those cases we follow the convention where everything goes in
I really like RPM for this reason. However, as you stated as long as the systems the RPM was compiled for is roughly the same it will work well. Which is why we standardized on one distro.
--
Garett
Where are the programs? (Score:2, Insightful)
Where was the program?
It was not in the K menu.
It was not on the desktop.
It was lost.
So I thought something went wrong and installed the RPM once more but it claimed the rpm was already installed.
I eventually realized it was indeed installed but the installer did not:
- ask me whether to put an entry in the menu
- decided for itself where the files were supposed to be
Never mind that I wanted the files to be in my home directory.
Never mind that I had no clue what the primary program name was.
There were dozens and dozens of other files in the RPM, mind you. It is not easy to determine what is a binary and what is not when you have just installed Linux for the first time.
And this does not even touch the subject of dependency hell. I have wanted to install several programs only to give up because of a huge number of dependencies.
Source-based and minimalist distributions (Score:2, Insightful)
For linuxes the various source-based approaches are becoming more popular / solid. In addition to Gentoo, there are Sorcerer Linux and two working forks (Lunar and Source Mage) see summary [sorcererlinux.org].
As pointed out in a comment above this one, when RPM snafus (often) you can usually build from source with minimal effort. Unfortunatley that's not true for RPM itself, which I have found to be a major pita to build from sources, or things like Gnome / E17.
Vendor unixes (Solaris, AIX, HPUX) put a lot of effort into correctly managing dependency checking. Part of their solution, however is in building their own versions of sources and staying as much as 2-3 years behind the current-releases of any given package.
RPM is a far cry from the vendor unix approaches, part of which I'm sure is that it's trying to do a much harder task on a less well defined base platform (random hardware).
Try building RPM from redhat's sources sometime, use the force you're gonna need it! That alone suggests to me that this is not in 'reality' an opensource project. A GPL license for software that doesn't build with './configure; make' doesn't seem like an effective oss project to me.
Just got ADSL, Just had a nightmare with packages (Score:3, Insightful)
I installed mandrake 8.2 a while ago, since then there have been a lot of 1.0 releases out.
OpenOffice,
Mozilla,
KDE (3.0.1)
etc....
But mandrakes packages have some rediculios deps, to install KDE 3.0.1 from there cooker(dev), it wanted me to update thinkgs like unixODBC and MYSQl,I don't wan't mySQL and call me stupid but obdc's a protocol!!! and i dont think the latest unixODBC changes that , why the hell have they put such non-granular pagkages togeter, if i had a release plan like that at work I'd probably be out of a job.
The RPM tree locations in mandrake used to be different from the package defaults which ment i could'nt install wines RPM and know i wasn't going to screw up package management some time in the future.
Dependencies of RPM's really need sorting out, and there should be no reason why i can install a suse package on redhat (so long as they both follow LSB!!)
grrrrrrrrrrrrrrrr
RPM not the problem.. (Score:3, Insightful)
This article wants solutions, so here is mine:
Make packages a seperate directory. Just like good old DOS days--where every program lived by itself in a directory. _All_ package contents go in this special directory. Then you have the problem of per-user configuration. This is incredibly simple. Have a directory in each user's directory which _mirrors_ the package directory. Each package directory should be unique (i.e. MyProgram v1.0 lives in a different directory than MyProgram v1.1). Dependencies would be much easier this way since you would only depend on a _directory_ existing. Moving packages would simply be a matter of packing up the directory and taking it wherever.
In any case, software is _package_ based. Why do we still throw library files from different packages together in the same directory?! When you want to remove a package you have to rely on broken package managers, or hunt down every file which goes with a package. We should be able to completely remove software by simply removing a directory. I've heard MacOS does this, why can't Linux?
The problem with this article (Score:5, Insightful)
Let us for a moment pretend that instead of using .debs (but still had APT, ala Connectiva), Debian used RPM for its package management. Would Debian be as good as it is now? Of course. Why is this? Well, because the Debian people spend a hell of a lot of time making sure the package management is done properly. This has drawbacks of course, like the lack of the latest-and-greatest software (notably XFree86 4.2 and KDE 3), but in terms of stability you really can't argue that Debian is the best around.
The author then goes on to suggest that a Gentoo-like system is whats best. Quite frankly this just shows us more about how little the author understands what is necessary in a package management system. Don't get me wrong, I like Gentoo a lot (in fact I type this message on a machine running Gentoo :)) but package management really isn't its strong point, as things like the recent libpng problems show. Doing things this way makes dependencies extremely difficult to deal with. Lets pretend you have libxyz installed, and then install program abc. abc can use libxyz, but doesn't require it. As you have libxyz installed, gentoo compiles abc with libxyz support enabled (one of Gentoo's best features). However, the day after, you decide to 'emerge unmerge libxyz' (remove libxyz for Gentoo virigins). abc no longer works properly. Gentoo didn't tell you that abc needed libxyz, because it's not a dependecy.
In my opinion, the package format is irrelevant; RPM, DEB, TGZ, all are fine as long as they are centrally controlled and well put together. A system like APT makes things many, many times better, becuase it eases dependency problems, but it isn't a pre-requisite.
Re:cool (Score:1, Insightful)
This article wants solutions, so here is mine:
Make packages a seperate directory. Just like good old DOS days--where every program lived by itself in a directory. _All_ package contents go in this special directory. Then you have the problem of per-user configuration. This is incredibly simple. Have a directory in each user's directory which _mirrors_ the package directory. Each package directory should be unique (i.e. MyProgram v1.0 lives in a different directory than MyProgram v1.1). Dependencies would be much easier this way since you would only depend on a _directory_ existing. Moving packages would simply be a matter of packing up the directory and taking it wherever.
In any case, software is _package_ based. Why do we still throw library files from different packages together in the same directory?! When you want to remove a package you have to rely on broken package managers, or hunt down every file which goes with a package. We should be able to completely remove software by simply removing a directory. I've heard MacOS does this, why can't Linux?
Re:standardized locations, etc. (Score:3, Insightful)
>fact that GNOME and KDE are mindlessly cloning it).
>The registry causes more problems than anything else
>I've seen on a Windows system. The MacOS did things
>right -- let all your centralized databases just be
> caches for data that can be rebuilt from files around
>your system.
Umm. KDE works exactly the way you describe MacOS as working. All of the KDE config file are just that, files. However, to aid performance, etc, they are built into a sort of binary "registry/database" by a program called kbuildsycoca. If it becomes fubar'd then you just rebuild it.
Re:Talk about a gimmick (Score:5, Insightful)
Not really... (Score:5, Insightful)
Let's see:
1. An RPM-based distribution is risky to upgrade
Not quite. Red Hat, for example, still supports upgrading from Red Hat Linux 4.x to current versions, if you use the official updating process.
You can run into problems if you upgraded some stuff by yourself, which is true for any package manager. A good package manager doesn't downgrade packages during an upgrade process. How is it supposed to handle an "upgrade" from a custom kdebase 3.0.1 installation (compiled with libc 5.x) to the kdebase 3.0.0 package found in the distribution you're trying to update to?
Downgrade things in the process? I think that would make people complain, as well.
Similarily, apt-get works quite nicely for Conectiva users.
2. A more complex binary RPM package is often hard, if not impossible, to install
Again, this is not exactly specific to RPM. The problem here is that RPM is used much more widely than any other package manager, therefore RPM packages are typically built on a wider range of potentionally VERY different systems than other packages.
If, say, 200 distributions used
3. The incompatibilities between different versions of the RPM Package Manager added another layer of complexity.
This is true, and the only real rpm specific problem.
There's always a tradeoff between new features and backwards compatibility, and rpm does seem to lean a bit too much towards new features.
4. The developers are forced to consider differences between distributions and create multiple binary packages.
This is just restating point 2, and is just as invalid.
Same for the suggested "solutions":
1. Learn to build your own RPMs
This actually does fix some problems... But of course you can't expect everyone to do it.
(See also #5)
2. Petition the RPM distributions to adhere to common standards.
Nice in theory, but because there's no real standard ATM, this would mean breaking compatibility with older versions of the distributions (by e.g. adapting a common scheme for naming packages so you won't need to make a difference between Red Hat'ish "Requires: kdelibs >= 3.0.0" and Mandrake'ish "Requires: kdelibs3"), possibly breaking the update path.
3. Use more advanced package management tools, such as urpmi or apt-rpm
I agree with this one (add up2date to the list, btw). The availability of those tools shows that rpm is actually a good and flexible package manager - it just needs some extra tools to simplify some common tasks. It's really the Unix way of doing things - have the tool do one job, and have it doing that one job (handling individual packages without resolving dependencies by itself, in the case of rpm) well. Then write other tools making use of the tool (rpm) to get more advanced functionality.
4. Switch to Debian or Slackware
As shown above, their package managers do not solve the problems mentioned in the article. The problems just happen not to show up so frequently because there aren't many distributions using these package management systems, and the ones that do are usually pretty close to the distribution they're based on. Much closer than completely different distributions like e.g. Red Hat and SuSE, which really don't have much in common except for the package manager.
If, say, Red Hat switched to using
So this switch wouldn't gain anything.
5. Switch to source-based Linux distributions, such as Gentoo or Sorcerer
This does solve the problem, but introduces others. It's a good thing for some people, but certainly isn't a universal solution to all problems.
Source based distributions are really nice for people who want to tweak things a lot, but they aren't very useful for a traditional desktop user (who typically doesn't have all that much of a clue and doesn't want to spend a lot of time learning), and they introduce problems even for users who can handle them.
Let's assume you have a source based package manager that is dumbed down enough to allow a user to install a package by clicking on a package file in Konqueror or Nautilus.
Here's some of the problems you'd still need to solve (and some of them really aren't fixable):
This is a real problem on slower machines - Compiling, for example, OpenOffice takes approximately 13 hours on an Athlon 1800 with 1.5 GB RAM. Imagine installing it from source on a Pentium with 128 MB RAM...)
foo.cc:123: invalid conversion from `const void*' to `void*' is supposed to mean? (It's typically an indication of broken code that happened to work with gcc 2.x, but doesn't work with gcc 3.x anymore - but how does a newbie know or fix it?)
Besides, rpm is powerful enough to provide this functionality for people who want it, combining the best of both worlds - it's typically as easy as
rpm --rebuild foo-1.0-1.src.rpm
rpm -ivh
This still has the same problems as a pure source based distribution, but with rpm, you get the choice between building from source and installing the binary.
It's the primary reasons why I prefer rpms over debs, by the way - they're much easier to build.
Re:Automaticness (Score:4, Insightful)
No. I'm going to have to strongly disagree here.
Your complaint is valid and reasonable, and unfortunately ignored by the Linux community, but your solution is not.
Your complaint is that you want a simple *user interface* to install large pieces of software. This is reasonable. There is not front end that I know of that's widely used that chooses a reasonable subset of packages in a large software package (like GNOME) to install. You have to select all the packages in the system, one by one. That's fair, and should be addressed.
Your solution, however, is not a good idea. The Windows method of having a single installer puts you at the mercy of sitting down at the machine and actually clicking and installing stuff. It puts you at the mercy of what features are supported in the installer, how old the installer is, etc. The Linux (well, RPM/deb) approach is to separate the program from the packages. Upgrade the program, you get more features/bugfixes. You can install every piece of software remotely (ever watch Windows administrators run around installing a new piece of software on a network? What could be done securely on Linux with a bit of setup with sshd and public keys and then a single command to install software on every machine involves the IT people running around to each machine and clicking "OK" and watching progress bars). If you bundled all these packages into one large package, and someone doesn't *need* all of them, they need to download extra data. If you need to install, say, GNOME on every machine on the network, you only have to transfer the few RPMs *your* users actually require.
The solution is a fix to the front end, not to the architecture of the system. We need a single checkbox that installs a good default subset of packages for a large software package. The "GNOME" checkbox would install gnome-core, gnome-libs, etc, but probably not glade. The Linux rpm installation architecture is superior to the Windows installshield architecture -- now let's make the user experience as nice for novices.
Re:The problem with ANY packaging system.... (Score:3, Insightful)
Suppose that Maynard has package libPease.1.4.2.thursday.5-31-41.1-pl3-build6 installed, which is supposed to be back-compatible to package libPease1. When he builds his
Same problem. Only if your packaging system does not allow subversions of a package can you avoid this problem. And if your package does not allow subversions, then if I really do need a feature of libPease.1.4 or later I am screwed - I cannot spell that out in the packaging system, so somebody will install my package when they only have libPease.1.0. Then I have to tell them at runtime they don't have the correct package.
A partial solution would be for every package to supply a list of packages it is backward compatible with, and for the installer to check that list when installing a package. Then, when you install SuperFlyFloobyDust, the install can say "OK, libPease.1.5, can you take the place of libPease.1.4.2.thursday.5-31-41.1-pl3-build6?", and libPease.1.5 would have to be able to answer that question.
This is not a full solution, however - libPease.1.4.2.thursday.5-31-41.1-pl3-build6 could be some bastard version that has a functionality that was not incorporated into libPease.1.5, and libPease.1.5 might not ever have HEARD of it.
Additionally, SuperFlyFloobyDust might NOT really NEED the functions of the bastard version, and so even if libPease.1.5 could correctly state "No, I am not a total replacement for that bastard version", SuperFlyFloobyDust could actually run on libPease.1.5, but due to being packaged by an incompetent boob, the program won't install.
File or package dependancies are the same. Unless you forbid sub-versions, you have this problem. And if you forbid sub-versions, you introduce other problems.
Re:Not really... (Score:2, Insightful)
As shown above, their package managers do not solve the problems mentioned in the article. The problems just happen not to show up so frequently because there aren't many distributions using these package management systems, and the ones that do are usually pretty close to the distribution they're based on. Much closer than completely different distributions like e.g. Red Hat and SuSE, which really don't have much in common except for the package manager.
If, say, Red Hat switched to using .debs, you'd immediately run into the problem that, due to totally different base systems, Red Hat .debs wouldn't run on Debian without changes and vice versa.
This is surely due to the various distributions not conforming to the LSB and FHS, rather than the shortcomings of the package management system? Debian is far more standards-complient than RedHat, and Slackware is even better.
With the version of apt that comes with woody, you can choose from which version you wish to install the debs from.
For example, you can track woody for the most part, but if you want the occasional package from sid you can do that too, and it will work out the dependencies automagically. The same would be true for multiple distros - just give it a different name and add the entries to your sources.list file.
My current system was originally Progeny Linux, which was then merged with woody, then sid. Using apt, I had no problems moving between systems.
Sure there were some incompatibilities between the packages, but the deb format is robust enough to at least identify the problems (and in some cases offer a solution). This, I believe, is where RPM falls down.
--teamonkey
Why I keep going back to Debian (Score:2, Insightful)
I've used SuSE, RedHat, Mandrake, Debian and a few others in the past. I keep thinking that a distribution has enough new features to warrent me changing, and then I hit the dependency problem and go back to Debian again.
This happened a few weeks ago when I installed SuSE on my old laptop because of its PCMCIA support. In the end I has so much trouble finding a RPM and its dependencies, I gave up and stuck woody on there. It took longer to set up, but I just need a net connection and apt.
I'm tempted to switch to Gentoo, but then there's always source DEBs, aren't there :)
apt isn't perfect though. Over a modem it takes a few minutes to apt-get update, and hours to apt-get upgrade, but it does make it so much easier! Also, Debian are very anal about their distro, even about unstable. There are still no (official) KDE3 or Openoffice.org debs (mainly because they don't work on all the supported platforms), meaning that we do have to go hunting occasionally.
--teamonkey
The real problems in RPM (Score:5, Insightful)
The author summarizes his article in the following points:
- An RPM-based distribution is risky to upgrade.
.deb without following Debian's policy would make a mess out of it.
- A more complex binary RPM package is often hard, if not impossible to install.
- The incompatibilities between different versions of the RPM Package Manager added anotherl ayer of complexity.
- The developers are forced to consider differences between distributions and create multiple binary packages.
.deb packages if multiple major distributions used it with conflicting policies.
From my experience in the past few years, here are the real issues with RPM:That is usually true, but it's not the usage of RPM that makes it so, but the lack of a strict packaging policy. Applying the Denian policy to a RPM-based distro can make it much easier to upgrade. On the other hand, using
This affirmation makes no sense at all. If it was correctly packaged for your distribution, it will be as easy to install as any other package. If it was designed for a different distribution, it can also happen with dpkg packages. Please note that the package manager offers a mechanism to deploy binaries, all the rest is policy.
True. RPM is a mess in the point that it is not an implementation of a design, it is being continually modified in both design and implementation. RPM needs to be stabilized, continuing development should go to a different product.
Not RPM's fault. It would happen with
- Binary packages are not compatible between distributions, unless they're statically linked and conforming to some kind of packaging standard. Dependency to libraries doesn't mean much: that particular library can be compiled with different options in different distributions. It's not RPM's. Assume that distributions are 100% compatible only because they share a package format is a mistake. Third-party, distribution-agnostic packages should obey a policy shared by all distributions, and that's one of the major points behind UnitedLinux [unitedlinux.com].
- Allowing multiple version of the same package to be installed isn't a good idea at all. Packages are different in nature, some will allow multiple versions, others won't (e.g. binaries vs. runtime libraries). Doing so only makes the upgrade process harder. Debian simplified it using a good packaging policy.
Note also that, even in runtime libraries, you should replace versions that have binary compatibility. If you don't explicitly set a soname in the package name, this information is not available at the upgrade time.
- Very confuse, non-intuitive pre- and post- install execution order.
- Transaction processing and dependency resolution is too slow, due to file dependencies. As stated above, file dependencies should not be abused, and that can only be enforced by a policy.
- Too many unnecessary or confuse packaging features, such as triggers. If you have a good packaging policy, you will never need triggers. Read the librpm sources and you'll find hard-coded dependencies for a number of packages. That's stupid, and a symptom that you've done something very, very wrong and didn't notice it until it was too late because you didn't have a packaging policy.
- Moving target. Please stop adding features to RPM and modifying existing behaviour, otherwise we'll be always fighting against the package manager while trying to make smooth upgrades happen.
- Immediate configuration of packages after installation in a multiple-package transaction. Dpkg's deferred configuration is a better strategy.
Most of the other RPM problems everyone says when touting Dpkg's superiority are myths and can be emulated with RPM (even using Debian's alternatives or debconf with RPM -- diverts is something more complicated to emulate). Dpkg is indeed a superior package manager today, but what people usually see is result of Debian's policy and not a package manager feature per se.Re:The problem with ANY packaging system.... (Score:3, Insightful)
(Perhaps I should point this out earlier: I'm a Debian Developer, so consider myself biased.)
Yes, .deb alone can't solve this problem; but in cases like these the Debian Policy has some guidelines.
In this case, "libPease.so.1.4.2.thursday.5-31-41.1-pl3-build6" should be in the package "libpease1", version "1.4.2.thursday.5-31-41.1-pl3-build6". Other packages always do a Depends: libpease1.
The reason that the major soname is in the package name itself is because, binary API changes are supposed to happen when the major soname changes. This way, there might be a "libPease.so.1.xxx" and a "libPease.so.2.xxx" that are binary incompatible but can coexist together on a system; and so there will be "libpease1" and "libpease2" packages that can be installed together; but "libpease1" version 1.5 will replace "libpease1" version 1.4.2 during upgrade, because upstream says they're binary compatible.
As long as the binary API remains backwards compatible, then the "libpease1" package can be upgraded to 1.4, and packages that require 1.4 features can Depends: libpease1 (>= 1.4). If libPease.so.1.4 is not binary compatible with libPease.so.1.0, then it really should be called libPease.so.2.0. If it isn't, then upstream has stuffed up, so nag upstream about it (I've done it before).
This is the problem of the person who did the package, yes? She should test the package before releasing it to the world, just like any other software, whether in source code or binary form (especially in binary form).
No system can guard against incompetent packagers. But with RPM's file dependencies, it's much, much easier to make a mess.
On stability & servers. (Score:3, Insightful)
The 'Unstable' in debian terms does not mean the system is unstable, it means the package dependencies are unstable. It has nothing to do with running unstable code. It means that there is no guarantee a change will not break a lot of stuff and not be fixed for a while. It's not uncommon to try to install a package and find the dependencies don't exist yet... or they exist, but are an older version. That's what unstable is all about.
Secondly.. regarding server stability.
IF you build your kernels yourself (you should), and if you are aware of what services are running, system stability is not really an issue.
I know that debian is pretty much the only system where I *don't* run hand-compiled apache, ftpd, etc. You should know what's up in your system. In this respect, no system is more stable than any other.
No No No No No (Score:3, Insightful)
1> Consistency, everything is installed the same way, select what you want, and hit install. (I use Mandrake, and rpmdrake makes it extremely easy to install packages...
2) Non-bloatedness. I'd much rather have 20+ packages for KDE than 1 package. Yes, it'll take me a long time to go through them, but I select what I want, not what the developer thinks I want.
One really cool part about Linux is that I can change --anything--. I don't have to have a graphical interface if I don't want, in which case I don't need to install it. If I plan on using Gnome as my window manager, but want to run koffice, I only need to install the kde-libs package, and don't need all of the kde binaries..
When a small part of a large project changes, I only need to update that small part, instead of redownloading the whole package. Imagine having to download all of KDE to update a tiny KDE app.
Uninstallation is also simple, select the box, hit remove, and there's -no other prompts-.
BTW, There is an installshield for linux, it's any kind of RPM/DEB installer (RPMDrake, apt-get, alien, etc) and it's of a hell of a lot nicer and more consistent than any simlar idea on Windows
Re:haha, LOFL! (Score:2, Insightful)
That said one can get in via alternate methods and fix, but what a horror. One should back that etc dir regularly btw, windows does it automatically "Last good configuration". Woohoo.
Of course windowss still sucks
Re:The problem with ANY packaging system.... (Score:5, Insightful)
That is the point I keep trying to make -
Unless we start vet'ing packages for compliance with that simple idea, no package manager created can solve the problem.
Now, I will agree RPM has its warts - I agree that being able to depend upon a FILE, rather than a PACKAGE is a weakness. However, until we get an agreed-upon standard that a given file will ALWAYS be supplied by a given PACKAGE, this is an unavoidable problem - I've seen the same file supplied by completely different packages (e.g. the RPMs supplied by Abiword and the abiword packaged supplied by Ximian).
How would you create a
Again, the solution here lies not within the package system, but rather the package creators - until you get a means to guarantee that package maintainers are "following the rules" you will have these problems, be you Debian, RedHat, or Microsoft.
Perhaps what we need is for a consortium of distro vendors to create a mark of trust. A would-be package creator can sign his packages with a key, and ask to register that key with the Package Police. If the package creator proves he can package something CORRECTLY, his key is marked as trusted. If he starts screwing up, it gets marked as untrusted.
Perhaps we could even create a system by which end users could vote on a given package - positive trust points for good packages, negative trust points for badly packaged libraries. Of course, since there are always people who seek to screw such a system up, we would need people to review the votes those other people cast, and remove the people who abuse the system. Then we would be able to see whose packages were good, and whose were crap. Of course, there would always be the dicks who rushed to be the first to vote on a package....
Re:standardized Linux configuration files... (Score:2, Insightful)
I don't run any Linux machines any longer, and I would be enraged if somehow the 'we must make it easy to use' Linux people started trying to force a big 'standardized' structure down the throats of the larger Unix community. I switched to NetBSD in part because it's cleaner, it follows a tradition (all those O'Reilly books I've been collecting for years actuall MEAN SOMETHING), and it always works. Rather than installing and learning 'new-widget-number-twentyseven' to accomplish some admin task, I just research the way it's always been done, and it works.
To put it another way: we're in trouble when things have gotten so crofted up that you can't start out researching a problem in AEleen Frish's 'Essential System Administration' and all the other O'Reilly classics.
Re:Talk about a gimmick (Score:5, Insightful)
So while I agree that these distros are not as good as they sound, I disagree on the reason why.
Compiling from source gives you a ton of flexability. Most larger packages have LOTS of compile time options which can be tweaked. Looking at apps like sendmail, apache, samba, etc. each has optional modules you can use. Binary distros limit you to the options the distro maintainers include and that's it. Optimizing for your processor can make a huge difference in the performance of many apps such as media players, graphics manipulation, the X server, the kernel itself, etc.
I started with slackware about 7 years ago now, migrated to RedHat, got frustrated with RPM and dependancy hell, played with MANY distros, and finally settled on debian. Debian rocks. It's the best of the bunch in terms of package management, stability, package diversity, user support community, processor architecture diversity, etc. I prefer debian's package management over any other system I've used including any of the BSD's, AIX, solaris, hpux, OSX, and a few others.
Your mileage may vary...
rpm/deb solves the wrong problem (Score:4, Insightful)
Efforts to improve package system have focused on providing answers to such questions: standardization. Standardization is good but if you take a step back you realize that it is not relevant to provide answers to these questions. Specifying that this or that icon should go to some kde specific directory is totally wrong. It is the task of the package manager to provide such information, not to require it. All the package should provide is an icon.
A package is a set of files with some meta information, not a set of files that scatter itself all over the place based on some assumptions the package creator made. Given the meta information and the files the package manager should do the rest: copy files, insert menu items in relevant menus, etc. This is how apple bundles work. Another example of this approach is the war package format for servlet applications.
There's a lot of debate on whether
Re:There is nothing wrong with RPMs. Only packager (Score:3, Insightful)
It is not a problem with RPM (Score:4, Insightful)
So, why installing an RPM is a more hassle that installing a DEB?
Because there are more distributions using RPM, while DEB is used almost exclusively on Debian. Yeah I know there are Progeny and Storm, but they are not very popular and are using a sizable part of Debian itself anyway. When somebody decides to make a DEB package, he will make sure his package will work with Debian (and Debian only), and he can be sure that everyone that downloads his deb will be installing it on a Debian system. But when another person decides to make an RPM package, with current situation it is a very hard job to make sure his package are compatible with various version and various distribution.
This problem will be gone if every RPM based distro are following the LSB. Even if they are all following the LSB very religiously, it is still possible to encounter this sort of problem. Say a person is using a LSB 1.0 compliant distro, but he downloads an RPM package compiled for LSB 2.0, it still won't install on his system. But still LSB is a lot better than forcing a distribution monoculture to all Linux user.
KDE is not gnome (Score:3, Insightful)
KDE users configuration files like most other Unix-software.
There are some things debatable about the location of these files (in $KDEDIR/share/config and ~/.kde/share/config) but thankfully it's not even close to being a registry.
Re:Luke, use the source... (Score:2, Insightful)
You forgot to mention one thing though. You now have built an RPM...it is added into your database. If that rpm becomes a dependency for another package , it is easily found in the database.
Also, now that you have an RPM, if you have other systems, you can simply drop in the binary rpm on those systems. Sure, plain old source may work great...but have you ever tried to build a package from source on 20 different machines? Much easier to build it on one and drop the binary rpm into the others.
Re:Upgrading Mandrake & Debian packages (Score:2, Insightful)
Actually, I have tried Debian. I'm running it on a headless server at home that hosts my personal domain. I really really like it. It's my experience with this machine that opened my eyes to what can be done, and been the catalyst for my aggravation when it comes to upgrading Mandrake. If I ever have to reinstall Mandrake, I'm just going to ditch it for Debian. I really don't need bleeding edge packages as I want to use my system now, not work around issues.
Re:Binary Distros Are Dead (Score:3, Insightful)
Source is almost never significantly smaller than binary, and often is bigger. Consider bash:
-rw-r--r-- 26 root root 701486 Apr 16 21:14
-rw-r--r-- 24 root root 2144412 Apr 16 21:14
the system is auto-healing, meaning that if and when a new library is installed and the older one removed, all packages that rely on that library are recompiled against the new library.
In the case of rpm or dpkg, the system protects itself from damage caused by replacing a package that others depend on. Attempting to do so will result in a list of all of the packages which additionally need to be updated to work with the new library. If you're using apt (for dpkg or rpm), attempting to update a library will fetch binary upgrades for the packages which need it. Source Mage doesn't have the advantage here.
Day long? I don't know many with anywhere near the time for that. I can install a Red Hat Linux server on a clean box in all of two minutes from initial power up to fully functional reboot.
Re:apt-get is nice (Score:2, Insightful)
The problem is Mandrake. Or whoever puts out these RPMs.
"Oops, sorry, we're going to start doing everything on gcc 3.1 for the next version, so... if you wanted newer packages of anything, you're out of luck."
Or replace that with any of a million other things. It's not the software format itself, it's the distrobutions that insist on putting together all these RPMs so that you can't upgrade one without upgrading your entire system.
But some of us aren't yet advanced enough to switch to Debian or Gentoo or Sorcerer, so what can we do?
Re:.deb (Score:3, Insightful)
Actually, dselect has been known to drive users the hell away from Debian. Its interface is rotten, and the authors agree. It's unfortunate, since dselect and apt really do good things. It just takes a bit of adjustment to get used to dselect.
I was considering moving over to Debian myself before apt became available for rpm. I'm much less motivated now ; )
Re:Binary Distros Are Dead (Score:4, Insightful)
I'm also skeptical about your casual benchmarks. On Red Hat Linux, for example, key system elements like the kernel and glibc *are* selected based on your particular CPU. Almost everything else is compiled with -march=i386 -mcpu=i686 -- that is, optimized for i686 but still able to run on older systems.
Re:Binary Distros Are Dead (Score:3, Insightful)
Ive been using mandrake, and then I grab the cooker rpms, and try to figure out which ones to install for gnome2/gcc3.1. So far its been ok, but not an easy task. urpm mandrake tools help on which rpms have which files, but rpm should includes these. Ill nail my list of concerns, some are common.
1. rpms should list dep rpms. (this is my major bitch)
2. rpm installs should use the opt directory for major programs.
3. take bandwidth in consideration, dont make users download every locale, doc, extra themes. Allow a "lite" version to work. 85% of the public still use modems.
4. allow updates for cooker/beta rpms. you should be able to install gnome2 with a gnome1 system, and have both work.
5. update rpm databases with cooker rpms
6. ease of use, how many commands do you really use in rpm? add/remove with verbose, list files in rpm, list deps. why would you use grep to search an rpm? rpm -qa | grep blah, rpm should include pattern matching.
7. rpm database should include locations on the net for cooker, beta, etc rpms. An updated database. Microsoft updates work flawless with mirrors, we need this on linux distros. some kind of rpm -install-net bob.i386.rpm
8. graphical/ncurses gui. ya ya, command line is king, but cant we pretty up the install process a little? Even if its a wrapper to rpm, it would go along way to make things easier.
9. -ivvh options, when installing its nice to see which files are installed, and a progress meter, but can we meet somewhere in the middle, just list the files installed, and give a percentage number in front of the line? I hate scrolling back 40 pages on an install just to see the 10 lines of data I needed.
10. group rpms in directories, even if its only 10 directories like slack or use gentoo sources, anything that has 20 plus rpms should have its own directory. I like how SuSE uses symlinks on its filenames, you could do the exact thing with 1 directory of symlinks point to the sub directories with the groups. Easy for a release.
Anyone else notice the rpms that are current on rpmfind.net are from the PLD (Polish Linux Distribution)? Why are the Poles doing a better job than other distros! Mandrake makes 2nd on updated packages.
rpm its not a program, its an adventure.
-
CS under linux, does your cheat scanner block linux? YES.
Re:gnome, kde (Score:2, Insightful)
Gconf is also great because its easy as hell to work on. Either tinkering with the files by hand or from the command line or using the ever nifty gconf-editor. The schemas are available to the user to check out so no configuration variable is completely undocumented although they do not explain what exactly they are used for.
People forget the biggest problem with the registry is not the registry itself its the number of undocumented keys that take difficult to comprehend values. Microsoft makes it difficult to understand on purpose under the guise of making it so "You have to know what you're doing to mess with it" which roughly translates to "Even if you work for Microsoft you shouldn't be messing with it. Bill knows whats best for you."
The registry-like idea is a natural decision. If you have a set of programs that use a similar text based config file format and they store all their config files in the same directory, thats registry-like. If you're building a DE, you're going to build a configuration API so that people can get and set values without having to reinvent the wheel every time. Gconf just makes it easy on programmers, users and sys admins.
We shouldn't be zealots that hate all things Microsoft just because they're Microsoft. If you find yourself needing something Microsoftish that you don't like, think about why you really don't like it and see how you can not fall into the same trap they did.
Re:standardized Linux configuration files... (Score:2, Insightful)
Re:Binary Distros Are Dead (Score:3, Insightful)
Why, exactly. I think you've profoundly missed the point of the command line if you think that every utility that might benefit from pattern matching should reimplement it.
If you really do that a lot and despise the extra typing, try something like this:
alias findrpm="rpm -qa | grep -i"
On use of /opt (Score:3, Insightful)
Er, yes they are. Unix has sorted files by their type, rather than what application they belong to, for a very long time. This allows, for example:
If you want to address the files by what application they belong to, that's what a package manager is for. No distribution's packages can use
Re:On use of /opt (Score:3, Insightful)
Mozilla is in
Its pretty easy to modify your profile path, ldconfig, and make a simple standard, like anything not unix OS goes into
Using 1 directory for all your bins is a cluster fuck.
Re:On use of /opt (Score:3, Insightful)
Cool. All you have to do is define what add on application software means...good luck.
The FHS also says The directories
Mozilla should puts its bins in
Using 1 directory for all your bins is Unix
Re:On use of /opt (Score:3, Insightful)
Why couldnt we do the same thing in
BTW, when your using a linux box as a workstation,
IE. you are the local administrator, and should be able to do what you want. Using 1 directory for all your bins is not Unix, this is why you have
The point is, if you use single directories for applications, you can back the directory up, and install new software without touching system files. Why would anyone sane put system files in with application files? Microsoft have "Program Files", unix should use
Using the phrase "Its the normal way" is just rehasing the same mistakes. Improve...