Slashdot Mirror
Is RPM Doomed?
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."
Gentoo Linux uses a system called "portage" which will download, compile, and install programs from source (binary for some packages). It is fantastic. Similar to apt it will check for dependencies and get those also. But the use of source is what turns me on. I'm converting all my linux boxen to it. Even inspired me to slice up the disk on my Win2000 box and go dual-boot.
"More organs means more human." - Zim
If the other links are overloaded, you can read the story on my site. Maybe other mirrors should be posted in this thread.
Teenagers these days don't have as much sex as they want each other to think they do.
I administer a few RedHat servers, mostly 6.2, and 7.2 which each perform a different function. If an RPM is offered for a piece of software I need to install, I usually download that first.
If the rpm install fails, I will spend about 3 minutes troubleshooting the issue. If I can't get it to go, I download the source and compile from scratch. 9 times out of 10 this works without having to figure out dependancies.
RPM works great when the envirnment is exactly the same as the build envirnment. When it's not...well, it just plain sucks. Source almost always works without incident.
Really, there is nothing to difficult about:
./configure
make
su
make install
Although it only works for products where the source is openly available.
RedHat needs a compile from source package format that most people can figure out. srpms may do it, but I have no clue how to use them.
-Pete
Soccer Goal Plans
I think the biggest thing we need with rpm (and other distro systems) is standardized package locations.
You mean something like a Filesystem Hierarchy Standard? Or maybe even a Linux Standard Base?
Jay (=
(Is there a website that rates distributions according to their adherance to these standards?)
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, 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.
WWJD? JWRTFM!!!
The problem with ANY packaging system is overzelous dependancy definitions.
.debs not because of any inherent superiority of .deb, but rather because of the hard work of the Debian maintainers to make sure the packages are all set up correctly!
When Maynard builds his SuperFlyFloobyDust.rpm file, rather than specifying the dependancies as "I need libPease.so", he accepts the default "I need libPease.1.4.2.thursday.5-31-41.1-pl3-build6.so". So, even though any libPease.so would work, you get a dependancy failure.
This is a failing not of any specific package manager - ALL package managers have this problem. You don't see it with
Additionally, there is the problem of library makers not following the fscking standards - libNarf.1.1.so is SUPPOSED to be fully compatible with libNarf.1.0.so - if it isn't, then it should be libNarf.2.0.so! However, you get people making libraries that don't follow this rule, so as a result you have to have libNarf.1.[0-99].so in your system because of programs that depend upon their version of that library.
The solution to this CANNOT reside within the package manager - it resides in the distribution maintainer to refuse to deal with packages that break the rules.
However, all it takes is one person installing one program that breaks the rules, and that installation is screwed.
That is where distros like Debian and the *BSD's have the advantage - they are controlled by folks who won't let that happen. However, how many people install from the unstable branches, and why? Because that's where the latest, greatest, shiniest stuff is!
www.eFax.com are spammers
I think the biggest thing we need with rpm (and other distro systems) is standardized package locations.
.dll registration. On Windows, the only way the OS knows about a .systemwide dll is when you've added an entry to the registry for it. On Linux...run ldconfig, and it rebuilds the systemwide cache (ld.so.cache), which is significantly faster (contiguous, not incrementally modified, not modified by all sorts of other apps storing filename associations and the like) to read.
That's already done in the LSB.
The problem is that each rpm is required to contain a static list of files it installs *with pathnames*. The nice thing about this is that it lets you run rpm -qip foo.i386.rpm without executing any code (sandboxed or otherwise) to see the list of files. The stupid thing is that there then has to be a totally different rpm for every distro and every maintainer.
In addition, it means that the maintainers need to keep *two* lists of what files are in the package -- one list for "make install" and the other for rpm. This is probably the most annoying design decision of RPM I've seen. There needs to be a FILES file with a list of installed files with a gen-files script (that runs sandboxed to build FILES for not-yet-installed packages and is run at package installation time to generate FILES). Have the Makefiles read this for make install. This would make life easier for maintainers (one list of files to install), would make RPMs more reliable (no accidental adding of a file to the Makefile but not to the spec file), and would let an RPM work on any distro (if we ever get the gcc-2.7, gcc-2.96, gcc-3 stuff worked out).
even though the newer libraries could do the job of the older ones
This is true for minor version number increases, but for a major version number change, newer libraries cannot simply link to the program.
Also, the registry is a fucking stupid idea. (despite the 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. If something gets borked or corrupted...that's okay. Absolutely do *not* make your single copy of data a registry -- put the masters around the system, and let the centralized db be rebuilt if necessary.
Also, registries require "installations" and "uninstallations" instead of just copying files. You can just copy appropriate files from one system to another and run code on a Linux or MacOS box. On a Windows box, you're in for running installers to poke at the registry. And finally, I've seen tons of broken Windows installers that poke at registry entries and end up completely screwing up data that some other app uses. For example, a friend once had Sonique and WinAmp installed, but couldn't associate mp3s with either. I took a look at the registry -- Microsoft's two-entry file association scheme let the extension entry point to a nonexistent application entry, IIRC. As a result, the mp3 entry didn't show up in the Folder Options dialog in Explorer, and couldn't be reassigned, and WinAmp and Sonique kept giving errors when trying to grab associations.
The day any distro starts requiring a registry is the day I never touch that distro again. Right now, I can just uninstall GNOME if I want to do so.
Oh, and another thing. The Windows registry is a *massive* shared database. As a result, tons of stuff modifies it and causes internal fragmentation and loss of physical continuity between related keys. Then all apps use the registry heavily (God, I hate apps that poll it), so you get slow app launch times, that annoying disk churning that you hear on Windows boxes...rrrgh.
Take a look at
The registry is basically a hack, because Windows *used* to have what MS considered a worse scheme (.ini files). It isn't a very well thought out system.
May we never see th
Why do we still throw library files from different packages together in the same directory?!
Mostly because that's the point of libraries. Libraries allow code to be reused between applications - sticking them in application specific locations makes it somewhat harder for application A to use library B.
someone please correct me if I'm wrong, but doesn't this article suffer from a fundamental misunderstanding? you cannot compare apt-get to rpm files. apt-get is a system for installing .debs and their dependencies. there are similar systems for rpms (apt-rpm or red carpet).
.debs are just a single package file. so do source code files (a la gentoo etc), since alot of your source code out there wont even ./configure without the right stuff in place. where debian has apt-get to manage the dependency nightmare, gentoo has emerge.
.debs too). From an end user perspective even this is not a problem with a dependency manager in place. since it will find the "right stuff" for you.
.debs suffer from all the same problems he complained about rpms having, because
what he is really bellyaching about is the fact that some big rpm based distros (mandrake and redhat) don't come with free dependency management software. 99% of his anti-rpm comments are not even wrong, they are wholly irrelevant.
The last 1% that might have value is the fact that developers can't make a "universal" rpm due to all the differences in filesystem layouts among rpm based distros (note that this can a problem with
The syntax of UNIX config files is pretty standard (barring the occasional ugly misfit like sendmail -- use postfix instead).
And all the Windows registry does is give a standard format for storing individual values (how should I store a string, how should I store a DWORD) and provide a hierarchy. It says nothing about format or structure within a single app.
If you want to turn on, say, mail relaying in postfix on Linux, then you look for the entry called mail_relay (or whatever) that's commented out and contains a helpful set of comments right above the config entry. On Windows, the equivalent is to go into the registry to some unspecified key, create an unspecified value there and then set it to some unspecified value.
Of course, most people just use a front end on Windows -- like a preferences or options dialog -- because the registry is next to useless to actually interact with. You can do the same thing on Linux, which is done by GNOME and friends to make things more convenient for computer novices.
Also, if the Windows registry gets corrupted, you have a big problem. If a single text format config file gets corrupted, you can probably fix it yourself. If you can't...well, it's a single file down the drain. Reconfigure that single app. Your entire system doesn't become unbootable, a la Windows.
May we never see th
I started my Linux experience with SLS and a 0.99 kernel. Then I switched to Slackware, then flirted with Caldera. Then for a while I ran RedHat on my servers, before switching in about 1999 to Mandrake on all machines.
And then I decided to experiment with Debian on a test box, and fell in love. I now have it on my desktop, my laptop, and three out of my five servers.
Why?
The package manager. It just works. It just works reliably, installing all the right stuff, resolving all the dependencies. When there are conflicts (not often) it reports them and suggests remedies. In short, the Debian package manager is to all other UN*X package systems I've ever seen as a computer is to a tally-stick. No-one who has used dselect will ever go back to RPM.
I'm old enough to remember when discussions on Slashdot were well informed.
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.
Blaming GW Bush for the Iraq war is like blaming Ronald McDonald for the poor quality of food.
I don't know if you've noticed lately, but libraries _are_ packages today. GTK+ for example. Qt, ncurses, etc. And if a package creates a _new_ library, then not many people are going to depend on it. And if they _do_ depend on it, they might as well depend on the entire package being there--since the library is a _part_ of the package.
The idea of sharing arbitrary library code is a failed experiment. If I create MyProgram and then I create MyProgramLib.. not many people will ever use the library. The only case they _will_ use that library is if I _package_ it seperately, and make it a coherent entity itself--with documentation. This is why, IMO, going package-only and dropping the various */lib directories can only be a Good Thing. And this is how Red Hat, etc. do it today. They create dependencies between _packages_. If I create an app in RPM format that needs, say libgimp, then my package will depend on the _entire_ gimp package being installed. Not just libgimp. Why not just handle packages naturally?
I'd also like to point out the benefits of doing this:
- Package corruption will be detected immediately. When something depends on a package and a file is missing or corrupt then the package can be determined corrupt.
- Dependencies handled naturally. When a program complains that a file doesn't exist, I can pinpoint _exactly_ which package the file is in and can simply reinstall the package. No need to hunt down which file belongs to which package.
Dijkstra Considered Dead
Really, there is nothing to difficult about:
. cgi?attack_linux+attack/%{name}-%{version}.tar.gz
/sbin/ldconfig
/sbin/ldconfig
/usr, but after you do this, note the names of these files in the package and specify them individually
./configure
make
make install
And all RPM does is automate and standardize this process. The strength of any management system is based around its ubiquity. Installing software outside the packaging system is a bad idea, as suddenly all those standard installation, uninstallation, querying, and verifying systems no longer work - for your unpackages apps, and all the broken packages or other unpackaged apps that rely upon it. Stop thinking of RPM as being seperate from source. it isn't. An RPM is a cpio archive with a source tarball and a spec file like the one below which automates the build process.
Summary: An addictive and frantically paced puzzle game with cute 3D graphics
Name: crack-attack
Version: 1.1.7
Release: 2mm
Source0: http://aluminumangel.org/cgi-bin/download_counter
License: GPL
Group: Amusements/Games
URL: http://qcd2.mps.ohio-state.edu/attack/
Packager: Mike MacCana
BuildRoot: %{_builddir}/%{name}-%{version}
BuildRequires: glut-devel
Requires: glut
%description
Crack-attack is addictive and frantically paced puzzle game with cute 3D graphics, playable either against the computer in single player or across a network mnultiplayer, where o
ne players success clearing blocks dumps large immuntable tiles upon the others block pit. Muahahahaha!
%prep
%setup -q
%build
%configure
make
%install
%makeinstall
%post -p
%postun -p
%clean
rm -rf %{buildroot}
%files
%defattr(-,root,root)
/usr
This will catch all the files installed in
%doc AUTHORS COPYING INSTALL NEWS README
%changelog
* Thu Apr 11 2002 Mike MacCana 1mm
- Created packages
Now I'm going to sit back down on my Red Hat 7.3 box and apt-get dist-upgrade all my RPMs from Freshrpms.net
You're so wrong. I've switched to Gentoo and won't go back to binary distribution, ever. Compiling from source allows you to, for instance, automatically compile anything that can use LDAP, for instance, with that support (or not, if you don't want it). Similarly, support for SSL, Kerberos, postgresql, etc, and many, many other optional "features" can be universally turned on and off in everything you compile. I've found it extremely annoying in the past to install an RPM only to find that the rpm maintainer didn't select compilation options that I need, so I'd wind up having to recompile anyway. Now I know that every single package on my system is compiled with exactly the options and library support I want. Not to mention my entire system (glibc, KDE, kernel, etc) is compiled with -O3 -march=i686 (etc) which has noticably sped up my system.
Please Rate my comment (and help support Fre
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.
This message is provided under the terms outlined at http://www.bero.org/terms.html
But software should install in linux the same way that it installs in windows. There should be one file, like setup.exe
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.
May we never see th
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.
- 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.It isn't the packaging format really
Source Mage and Gentoo[1] are two excellent source based distros that avoid these classes of problems altogether, and unlike RPM (or debs[2]) add no burden to the upstream software developer.
Shawn Gordon of The Kompany touches on this when he says (from the article, you did read the article, right?)
Source based distros like Gentoo and Source Mage have packaging systems that automate the process of downloading, configuring, compiling, and installing all of the software on their systems from source (pedants will note there is the occasional binary package, e.g. NVidia drivers, but for the vast, vast majority of software my point holds). Indeed, this approach makes the packaging system itself less important (so long as it works properly) than the overall engineering and organization of the distro itself, and completely irrelevant to the software developer (as it should be).
This has a couple of disadvantages, and a whole bunch of real advantages. So much so that almost no one who has used a source based distro will go back to a binary based distro once they've tried it, despite the cons (in fact, of the numerous people I know who've tried Source Mage and Gentoo, both very different from one another BTW, I know of not a single person who has gone back to their old binary favorite, be it Suse, Mandrake, Red Hat, or Debian).
There are numerous other advantages I could add here, but you get the idea.
The entire article on the flaws of RPM might better be entitled "The Flaws of Source Based Distributions" which, in the age of Free Software and source code availability, coupled with todays fast processors, really ought to become a thing of the past. In fact, it wouldn't surprise me at all to see Debian, Suse, Mandrake, and Red Hat all embracing the notion of source-based distros sometime in the future
And the advantages in speed, stability, and ability to keep current with new software releases in a timely manner will only become more acute as time goes on.
So while binary based distros are by no means dead (despite my rather provocative headline), it is my opinion that the writing is certainly on the wall, and the ovservant person can already mark the shifting change in the wind.
[1]There are other source based distros as well, including Linux from Scratch and Lunar Penguin, and likely others as well.
[2]Though in fairness the Debian developers take up most if not all of that burden
The Future of Human Evolution: Autonomy
This is not the issue. It has NOTHING to do with the compiler. I have played with both sorcerer and gentoo and problems with it were that the distributions were never stable, and things frequently broke due to the constant state of flux. They had no concept of debian's stable, unstable, and testing branches. Basically, package maintainers didn't test - changes were made on the fly to be "current". Multiply that by the number of package maintainers. While this is fine for playng around, it's totally useless for a business and THAT is the problem with those distros.
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...
You must be new to UNIX like systems. You see there is a reason we don't have 50MB executables from all the static linking and DLL hell. We use shared objects between all apps to save disk space, development time, and main memory. I see you complaining about rpms, so maybe you should try a distro like Debian GNU/Linux, and expand your horizons.
For example if we did shar archives ( what you want with your 'setup.exe' ), then you'd have to install all of KDE to just get QT libs. You'd have to install all of GNOME to get gtk+. You see why that's piss poor way to do things just from a packaging standpoint even if you don't understand the techincal aspects? Also versioning would be impossible to support. Versioning is allowing multiple libs to stay on the system without conflicting, so apps can use various versions as they choose. To support versioning you'd have to have N number of KDE installs.
I don't see how that post go modded up, when it's so misinformed... oh this is slashdot.
The key to figuring out why a particular solution is not working is trying to figure out what problem it is trying to solve. Why do we need a package format like rpm? Because linux applications tend to consist of a lot of files which need to be put in the right places. Doing this manually takes time and is error prone. Types of files may be icons, images, executables, man pages, fonts, .... In addition to these files scripts are bundled that may do configuration, clean up after removal, move files to the right directory etc. Making this work requires that the creator of the package makes a lot of assumptions like where do icons go on this system? What is the right place for an executable? Where do the man pages go? How do I add a menu item to whatever window manager is installed? ...
.deb or .rpm is better. IMHO they are equally flawed. The only reason .deb works better is because there are fewer .deb based distributions (i.e. debian and a handfull of very small debian derrivatives). The .deb format is not plagued by differences between distributions because there's effectively only one distribution: it avoids the issues rather than solving them. Try unleashing potato based kde .debs on the latest unstable debian and you will find yourself in .deb hell (ironically most debian potato users end up trying to do the reverse: install the latest kde .debs on a potato system).
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
Jilles
"The problem is not using the hierarchal file system in a coherent way."
/bin,/lib,/etc, etc. has many many advantages over the "good old DOS days" -- ESPECIALLY when you start mixing in NFS and automount. Some examples:
/etc directory is architecture and OS independant so you can share the same directory accross all three. The /var directory is achitecture independant but depending on your set-up it will probably not be OS depandant. Thus you can discern the differences between the OSs yourself and set up an automount variable to mount the proper version per OS. The /lib and /bin directories are both OS and architecture dependant. In that case you must set automount variables for OS and arch and mount different dirs for each.
/bin and /lib for each. You need to change some defult configs for all the clients? Voila, just edit one config file! Could you share one program accross multiple machines, architectures and OSes in the 'good old DOS days'? Could you immediately upgrade 65 workstations to the newest version of a program without reboots and only use 1/65th the space (aka one copy) in the 'good old DOS days'?
/usr ro. You can optimize your RAID array for fast read and writes in the /var mount while optimizing /usr, *lib and *bin for fast reads, etc.
I hear this argument every time package managment is discussed on slashdot and every time I bite my tongue.
The current system of
* all SHARED libraries are in the same place. That way the dynamic linbker does not need to do a ridiculous path search to find a library
* all binaries are in 3 -4 places -- that way you don't need a massive PATH variable like 'the good old DOS days'
* because the files are sorted by type, you can do all types of neat things. Let's say for instance that you have Solaris SPARC, Tru64 Alpha and x86 Linux boxes all sharing a single NFS server. Now the
Let's say that you install emacs network-wide. You share the same config accross all your NFS clients and just make different
* Because the files are sorted BY TYPE you can do all types of neat optimization and security things. You can mount
'the good old DOS' system was good for what it was used for -- a small system for one user with a few programs and didn't need any optimization. The heierarchal system is a lot better here used as a multi-user, muti-tasking shared-library networked OS with hundreds of programs.
Now if you hate the heierarchal system that much, you can do what SCO OpenServer does -- install all the files into each 'program directory' and then make symbolic links into the heierarchal system. It would be VERY easy to do -- just write a script to query your RPM database for what files are in each package, move all the files for that package into its own directory and then make a symbolic link for each file moved back to the hierarchal system.
SCO liked the 'good old DOS days' also. The problem with OpenServer and all those symbolic links, though, is that resolving the symbolic links by the dynamic linker, the shell, the programs, etc actually was pretty expensive and gave a decent hit to filesystem performance. Furthermore it made NFS-mounted trees hell and you could not do all the neat optimization and security stuff that I mentioned above.
In summary, the heierarchal system is by far easier to manage for performance, security and for centralization. It is tougher to manage for "adding / removing" programs. The former highly outweighs the latter, expecially since you have package databases to help tell you where all the files are. Learn to use your package managment system.
The bulk of this article and thread seem to be once again people bitching about RPM dependency hell. The solution to that is download the source rpms and then do a rpm --rebuild [source RPM] then a rpm -i [/usr/src/RPM/RPMS/i686/[name of RPM built]. That solves 96% of all your problems and still maintains your RPM database. config, make works too, but it throws you back into the chaotic world of no package managment and thus completely defeats the purpose of RPMs.
Have a nice day!
If you take a look at comparison of various package management (http://www.kitenet.net/~joey/pkg-comp/), it is clearly shown that RPM and DEB have almost the same set of features.
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.
Yeah, there is couple of problems with RPM, but:
.spec file) :)
- it's easy to do upgrades (on RedHat, don't know about others) I do it several years from remote location, and only once it failed because of bad LILO configuration...
- you always know which file belongs to which package
- you can verify checksums of all installed files
- dependencies is not a problem - it's a solution to the problem
- it's simple to locate needed package from distro
- if you're trying to install someone else package, you'll better to get sources, and build rpm package youself
- I agree that it is bad idea to distribute rpm binaries only, so best is to post tar.gz source, rpm packages are optional (it is good if source includes
- and if you don't like dependencies, you can always use --nodeps
P.S. When I start using linux in 1995, first distribution I installed was Slackware, and after one year I switched to RedHat.
Slackware is a good, but you have same dependency problems (and you even don't know which package to install in case of such problem, lets say then installing some binary package). It also much harder to upgrade it....