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."
I think the biggest thing we need with rpm (and other distro systems) is standardized package locations. That would help, *extremely*.... as well versioning control needs to be better. For example, I hate having to have 2-10 different versions of libraries due to programs requesting their own version, even though the newer libraries could do the job of the old ones. As well, when the rpm asks for another rpm which is not installed, but the libraries are on your machine (in the right location) it is frustrating.
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.
===> An eye for an eye makes everyone blind - MG
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 fully appreciate the author's sympathies. I'm used to replacing RPM-based distros; just last night I burned a new Mandrake Cooker so I could try it. KDE3.01 et al are just too hard to get right using RPM upgrades. But then he mentions gentoo...
/etc (etc.!) files.
...which I have also tried to install. Trouble is, gentoo has *no* installer, past the kernel stage. I can't even get sound to work, becuase my mobo sound chip isn't in their ALSA tree. I'm sure there's a way to do it but they don't tell you. Gentoo users are typically, I suppose, the type of Unix experts who have no trouble figuring out which driver goes where. But gentoo lays things out differently from RedHat (etc.) so I can't just copy their
If gentoo had a decent installer, not necessarily as "friendly" as Mandrake (more flexibility is a plus) but which could guide all the files into the right places, then it might be a killer. For now, it's a cult for experts. But I don't see why a binary-based (or at least partially binary-based) distro couldn't use an apt-get or portage-like system when needed, without requiring gentoo's exceptional knowledge (well, that's what it feels like to the "n00b" whose recent Linux experience is mostly RH and Mdk) of the distro's layout.
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!!!
I hate it! You need to compile a new RPM for each platform
.tar.gz2 package which detects what OS your using, and compiles and installs automagically with an easy to use gui and a powerful cli interface
/i ce -20 rpm -tb "$@" && rpm -Uvh `find $our_rpm_buildroot -type f` && rm -f `find $our_rpm_buildroot -type f`
:-)
What we needis a smart
Well, hell.
------
#!/bin/sh
# Demonstration that RPM ain't all that bad
# Copyright 2002, 0x0d0a
# This code placed under the GPL
# Should compute proper buildroot, etc
# Be damn sure not to set buildroot to
# or something similar -- rm -rf would
# then suck severely
# Set our_rpm_buildroot appropriately
# Usage: mybuildrpm.sh foo.tar.bz2
our_rpm_buildroot=/usr/src/redhat
n
-----
Okay, I grant that there's no gui, but you get all the many CLI options of RPM. Voila!
People love to bash RPM, but it's a pretty sweet system (except the move to the newer underlying dbfile...screw transactions, I can always rebuild the database if it gets corrupted and it takes *much* longer to install and query than things did back with rpm 3.0). If it's too simple for you, it's really easy to use it as a back end and slap something on top of it.
Note: this is a one minute hack and may not even run, much less be safe for your system...it's an example, not intended to be used. And hell, running random stuff from people on Slashdot as root just isn't a great idea.
May we never see th
There's been quite a discussion on the installer issue in the Gentoo forums (the thread can be found here). The general consesus from the users seems to be that they like Gentoo being kind of a "niche" distro. If the idea of the source based distro really appeals to you, I would suggest giving it another go and leaning very heavily on the forums (if you need to). Gentoo's Forums have the most helpful and friendly user base I have ever seen on the internet. I have yet to see a single person give a n00b a hard time (outside of the occasional rtfm...). I realize that it's not for everyone and that it takes a little bit of work, but I think Gentoo is definitely worth it after the dust settles. It's nice to install an OS and feel like you actually accomplished something.
Oh yeah, and I don't like RPMs.
I aggree,
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
thank God the internet isn't a human right.
in itself. The problem is not using the hierarchal file system in a coherent way. In addition to that problem we have way too many files nowadays. When package contents mix with one another.. well I'm sure you've had Chem. 101.
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?
Dijkstra Considered Dead
What we need is to get rid of the entire packaging system all together. I know I'll probably get toasted for this. But software should install in linux the same way it installs in windows. There should be one file, like setup.exe. I should take that file, execute it, it will ask me what parts of the software I want, and where I want to put it, etc. From my experience there are two pieces of software for linux that do this, the Tribes 2 server, and Mozilla.
The entire packaging system is just a pain in the butt. This depends on that depends on this. urpmi, rpm -i, rpm -U, things not working with no explanation. In Windows I never have to worry about one thign relying on another thing. Because just about everything uses DirectX. And directX COMES WITH anything that uses it. And it has a simple graphical isntallation.
There should be one downloadable file for each piece of software I want. It should install on its own, on any linux machine, easily and graphically. And all of my library packages like glibc, etc. Should transparently update themselves to the newest versions all the time. I dont' want to have to worry about that stuff. Drivers in linux are incredibly difficult to install. They should become a simple right click, install driver. Done. I want all that other crap taken care of for me. I don't have time to change paths in config files, tinker with code, look up crazy commands and recompile crap.
I feel the package system is the real place in which linux fails. Most distros, lets use Mandrake as an example, have graphical easy installations. But when you get to the package selection phase you're stuck forever weeding through thousands and thousands of checkboxes. Not cool.
One piece of software should be one checkbox. KDE alone has like 20+ rpm files. There should be one file. KDE3setup.exe.
You know that installshield that almsot every piece of windows software has? Maybe someone could code that for linux. I would, but I have no idea how to do something like that. But I know someone reading this does. And if you want to save your open source os, I suggest you do.
The GeekNights podcast is going strong. Listen!
RPM by itself isn't the real problem here. The author is complaining that installing applications in Linux is a pain in the ass, because the system often doesn't have all of the required libs installed.
I admit, RPM doesn't make this an easy problem to solve. Any normal Windows app would simply package the required libraries with it. Thus if the lib doesn't exist, it can install it. But RPM doesn't work that way. RPMs can only hold one logical unit. So one app, or one library, or one set of platform independent support files. RPM builders could include more, but doing so will likely break the RPM dependancy tree.
The real problem in all of this is the destinction between applications and the system itself. Is grep part of the OS, or is it an addon app? How do you tell? Most would argue that grep is a part of the OS, but you can easily install linux without grep, so it must not be essential. But if packages expect it to be there, then it must be essential. But if it's not part of the OS, then they shouldn't have expected it to be there in the first place, so now it is their fault for not thinking ahead... This problem just goes in circles all day. The worst part about this is that my use of grep is just an example. This problem applies to literally all packages outside of the kernel itself. Don't believe me? How about init? Do you think that init is essential? I agree, but what version? Do you want a SysV init, or a BSD style init? Technically you can have either.
To solve this whole problem, we really need to take two steps. First we need to define a base Linux system. And I don't mean a completely solid, unwavering, definition either. Standards that never evolve are quickly dubbed 'legacy'. The trick is to define a complete base install. Everything from the kernel, to the version of GCC (and no RedHat, gcc 2.96 isn't going to cut it), to what version of X is installed, to what "expected unix utilities" are available, and what libraries are available. Feel free to change the standard, but each time you do so you must raise the bar somehow, either by making it more reliable, or faster, or adding features, or some combination of the above. There is only one last key item to making this system work. You must retain backwards binary compatability for long periods of time. Feel free to completely break legacy systems, but make sure that you only do so after you've had at least 5 to 6 years of stability.
Then there is the second step. RPM is a nice system management system, but it is a shitty application packager. Mostly because of the dependancy issues and the fact that each RPM package can only hold one logical unit. We really need an install shield like system for applications (both gui and console installs in the same package). Feel free to keep track of what is installed, and what files belong to who, but you really need to separate the system from the applications. Once you have a base defined, keeping the system and apps under the same packaging system no longer makes sense. The absolute need for it is removed.
Well I'm sure glad Linux uses /etc to store confiruation data. Having 50 different styles of configuration files sure does make one's life easier.
I'm a loner Dottie, a Rebel.
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
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.
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
Sticking feathers up your butt does not make you a chicken - Tyler Durden
Say your package directory was /usr/app (or whatever, there are standards for these things, y'know) libpng would live in /usr/app/libpng, qt would live in /usr/app/qt. Things could still dynamically link them, and it would still Just Work. The only difference is that you don't have four hundred files all crammed in /usr/lib.
/usr/app/libpng/n.m . Which is only a refinement, but which is much safer. In the case of large packages this would cost a lot of disk space (how many versions of KDE or Gnome do you want to keep on your computer?), but OTOH it would be a lot safer. You could keep multiple versions of even so prevasive a package as KDE or Gnome during development, and if one didn't work, you could revert to an earlier version. (Yes, something like this is done during development anyway, but that requires special fiddling, and changing the directories around when it finalizes, etc. This approach wouldn't. And deleting an obsolete version would be nearly as easy as removing the directory (well, you *would* need to check for dependencies).
/usr/bin directory to become composed entirely(?) of links. Still, I've done that already when trying out a new version of Python, and it didn't seem to cause any problems. (I suppose that the other bin directories probably wouldn't be affected that way. Especially /bin and /sbin, since they might be needed when other partitions weren't mounted.
Almost. I think that he was really proposing that libpng version n.m would live in
I guess that a side effect would be for the
I think we've pushed this "anyone can grow up to be president" thing too far.
I've seen a lot of this "dependency hell" and it makes me really hate dependency on .so's:
with a statically-linked build, it either works -- reliably -- or it doesn't work at all. I've heard
all the .so justifications before, and from my point
of view as a practicing fifty-year-old mathematician, computer scientist, and
environmental modeler, it is all a lot of bunk
when it comes up against the real practice of computing.
"My opinions are my own, and I've got *lots* of them!"
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
First.. you mentioned it, but I'm not sure everyone got it....
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.
I run a system based loosely on Linux from scratch, which adopts a link farm approach like you describe. My /usr/bin (and /usr/blah directories generally) indeed do have hundreds and hundreds of symbolic links. This probably impacts performance, but I've not noticed it on my K6-3/400 PC with old slow IDE disks. Using some simple perl scripts to create, retarget and clean up symbolic link farms, package management is simple. The key benefit is that the metadata associating a file with its package is the symbolic link itself - it is logically incapable of becoming out of sync.
My work-around for the root file system is as follows. Each package I keep in /usr/pkg/packagename-version. Things destined for /usr/bin live in /usr/pkg/packagename-version/bin and so on. Things which need to end up in (say) /sbin live in /usr/pkg/packagename=version/root/sbin. I cp -a the contents of these root subdirectories into /.
This mechanism is a comprimise, but works quite well. I can compare files in root fs directories against those in /usr/pkg/*/root to find which file came from which package. Updating is a simple cp -a.
Why not do the same for /usr, and avoid the symbolic link farms? Primary reason is that while copying into the root fs those files that need to be there might take up 30MB or so, doing the same for /usr would mean an extra 500MB or more of duplicated data. The other reason is that for those packages which aren't too tied to their location in the filesystem, differing versions can be present on the system simultaneously.
Packages are way better than Windows setup.exe.
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
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...
What I'd love to have in a package manager is a more intelligent dependency check. Like, instead of just saying "I need this version of X," it would also just check for the existance of /usr/X11R6. Or if a package requires BerkelyDB, after checking "inside" the package manager, just try and see if there's a libdb.so somewhere in the LD search path. And then mark down "inside" the package management system that the "BerkelyDB" or "XFree86" dependency seemed to be fulfilled by a manual installation.
That would be the ideal system for me.
Al Qaeda has ninjas!
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
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.
Actually, there is a limitation of .rpm that hinders the APT4RPM functionality-- file dependencies. .rpm archives depend on specific files, while .debs depend on specific packages. This can be worked around, essentially by creating a list that maps files-that-are-depended-upon to packages-containing-these.
But yes, there is at least one technical superiority of the .deb file format. I have never heard any argument that .rpms have a technical superiority to .debs, so I have to wonder: why don't RPM-based distros don't switch to deb? They could just adopt the .deb file format as RPM 5, make the tools speak deb, and stop worrying about it. They'd serve their users better and reduce duplication of effort.
Or perhaps users should take it into their own hands. Using tools like 'alien', it might be possible to take the apt4rpm approach one step further-- create an unofficial 'Redhat .deb' distribution-- the same packages as Red Hat, but in a different package format.
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.
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....
What if, when you wanted to perform a binary installation, it checked dependancies the same way that autoconf-like programs do... tries to find them in particular locations, and creates a configuration file for that program based on what it found? It can do version checking as well, and report any mismatches to the user. In situations where there isn't a clear-cut place to put such a file, the installer could create a bourne shell startup script instead. It would work everywhere, and wouldn't be dependant on _any_ rpm or deb databases.
I realize that this would require one new file (either a config file stored in the program's library directory, or a shell script used for startup), for each package that gets installed, but we're already looking at wasting space with the rpm or deb databases anyways.... this solution wouldn't take up any more space and has the added bonus of being completely cross-distribution!
For library packages, it shouldn't even need to store a config file... it can just check the versions of the software or libraries that it does require and report back to you. The job of actually finding the libraries as they are needed can be performed by the linker, which is presumably set up to search applicable directories. Heck, if it's not, even this information could be reported at installation time too!
File under 'M' for 'Manic ranting'
Configuring how packages are compiled in gentoo can be set with the USE environment variable, or editing it in /etc/make.profile/make.defaults. There are many useful options that can be set there.
Compiling is done with the "emerge" command for that package. Just for grins if you want to reconfigure *everything* with a new set of interesting compile parameters, simply type:
emerge world
And watch the CPU happily crunch away on every line of code that is currently installed on your system!
"emerge rsync" updates the packaging tree. Then you can update packages, system, or the world with the -u option.
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