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 don't have problems with RPMs at all. I use apt-get since it was first introduced in Conectiva Linux, and I'm now using it in a Red Hat box. I upgraded it from 7.2 to 7.3, and the only problem I had was lack of space in /var to download the files (not my fault, but from the former sysadmin).
various alternatives to RPM packaging? I don't know much about this, but I've found QNX's Package Installer to be quite efficient and trouble-free (at least in 6.1, can't say much on the new one in 6.2NC) compared to what many experience with RPMs..
Then again, RPMs would work better if more distributions were a little more uniform in their cores (UnitedLinux might solve this?)
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.
No depency checking, but it also means that you don't have the problem of circular dependecies and the like. Plus you can open it with tar and gzip. Linux Packages is a great place to look for pre-built Slack packages.
I used to use RPM, but now that I've converted to Slack, I don't miss it one bit.
"Backups are for wimps. Real men upload their data to an FTP site and have everyone else mirror it." -- Linus Torvalds
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.
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?)
From the article...
> On the other hand, have you noticed how hard it is to find Debian ISO images?
http://www.linuxiso.org - I can't believe you've never heard of this place. They've had Debian ISOs since I first learned of them.
I admit, debian.org's ISO download wizard is garbage, but I think they're trying to save bandwidth by having you download what you need instead of the entire ISO (there's no reason you need to install every package in the ISO).
niko
> I administer a few RedHat servers...
:)
Once you administer 20+ of 'em with other admins, you are going to need a package management system.
Unless you think keeping notes really works
---
blaze-x
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
This situation (and ones like it) happen all the time. That's one reason why programs often get their own copy of a library, even though it sucks from an end-user standpoint.
Nevertheless, you're right....versioning needs to be better.
The registry in Windows creates a single point of failure. The point of the registry seems to be copy protection. The registry contains incomprehensible data. It is an area meant to be outside the user's control.
Okay.
What features of the solaris package management and/or solaris packages themselves do you want to see? Because if it's just about nice, neat clean packages that install trouble free.... well, let's just say it's entirely easy to produce a solaris package that sucks.
The point is.. RPM is not the culprit; multiple vendors using the same package but systems that are rather different sucks.
debian packages work well because the debian world is rather focused. Because we ensure that all dependencies can also be met from debian packages in the same distirubtion, etcetera.
If you use redhat and only redhat official packages, it works great too (well, insomuch as redhat can work great)
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.
/usr/src/redhat/RPMS/i386/package-version.arc h.rpm
.tar.gz you extracted has a spec file:
/usr/src/redhat/RPMS/i386/package-version.arc h.rpm
rpm --rebuild package-version.srpm
rpm -Uvh
Or if the
rpm -bb package.spec
rpm -Uvh
Does the name Pavlov ring a bell?
While I agree with the thrust of the article, it would be much more persuasive with a little more meat behind it.
"There is at least one distribution (ESware) that has moved from RPMs do DEBs, but I don't know of any movement in the opposite direction."
A little research into just how many distros have migrated one way or the other in, say, the last five years would be instructive.
"Similarly, there are many users who have moved from RPMs to DEBs, but very few who have chosen the opposite path."
This statement is pivotal to the article, but is completely unsupported by any hard numbers, and comes off overly broad. (Surely there must be have been SOME attempts to determine market share of the major distros?) Maybe you don't know anyone who's gone the other way, but I'm sure it happens.
That said, there's a lotta truth in this article. After a couple years of struggling with RPM Hell on Red Hat and later Mandrake & Yellow Dog, I've recently decided to switch over to FreeBSD (ports, yum!) on my server and Debian on the workstation.
Oh, as an aside, there's an implementation of deb/apt for Mac OS X and Darwin, called fink. Fink supports both binaries with apt-get/dselect, and source installs with their own ports-like tool. I know a number of people who run traditional Linux/Unix progs, including X Windows, The Gimp, KDE, etc., side-by-side with their regular Mac apps. Oh so very cool.
Learn from the mistakes of others. You won't live long enough to make them all yourself.
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
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.
Really, there is nothing too difficult about:
l
./configure
make
su
make install
Yeah. But there's the ever so much more superior checkinstall:
./configure
make
su
checkinstal
This creates and installs an RPM of all the stuff you were installing. Voila...you can uninstall, you can query rpm to find out what package a file is part of, find out if uninstalling something will break dependencies, etc, etc...all the stuff that you can't do with just make install.
May we never see th
Ladies and gentlemen, I hate to be the one to inform you, but this isn't RPM's fault, this is the individual distro vendors' faults for not standardizing on a filesystem hierarchy.
I also blame the users who don't have enough sense to build thier own rpms. It's not *that* hard, if you have a SRPM, to build an RPM that works on your system where the binary may have failed. In fact, I recommend that if you use RPMs that don't come from your distribution vendor, you get the source RPM, edit the spec file as appropriate, and build your own...this way you're linking against *your* version of whatever libraries you have installed. It's not *that* hard, trust me.
-Jeff
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
Sticking feathers up your butt does not make you a chicken - Tyler Durden
My second pet peeve with RPM is that you need to be root to build an RPM from source.
No you don't! I regularly build packages from source in my home directory. I've occasionally had silly failures because the person who built the srpm hard-wired /usr/src/redhat into it... but that's (as the start of this thread tried to make people understand) the fault of the maintainer. Not the package format.
We all know that crap is king
Give us dirty laundry!
Not really. GNOME's GConf works like a database (installable schemas with defaults) with any back end you want (XML, LDAP, Postgre, raw files). It's only used for configuration (e.g. user preferences) not anything critical, so you can blow it away or damage it and your system will return to reasonable defaults. You should also be able to share them between different installations, and have a registry chain so that defaults can be maintained on a central server and users can make local changes on their servers. It also has notifications so you can be notified if a specific key changes. With notifications, there's no need to restart your application (or server) just so that the new settings can take place (no reboots either!).
Windows registries are nothing like this.
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 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!
Anyways, I'd just love to point out that debian has a system in place for this. There is a beautiful program called update-menus. Almost every debian package supports it, and it allows menus to be consistent through every desktop environment.
They who would give up an essential liberty for temporary security, deserve neither liberty or security
RedHat has a HOWTO at RPM.org and I've written documentation for bluelinux.org which should be helpful.
My email is real.
I must agree whole heartedly with this comment.
I'm a redhat user myself, and have tried downloading binary RPMS and seen RPM-hell first hand. I found the same solution: download the source RPMS!! A quick rpm --rebuild package.src.rpm will usually do the trick.
I have seen some cases where this does not work (some developer wants the latest ALPHA version of some library). For this I blame the developer, not the distro.
Actually, rpms can depend on files and/or packages. Either way.
But as for switching RPM-based distros to dpkg: RPM doesn't map 1-1 with dpkg. I don't want to get into a big relgious war (although, that's pretty much this whole story...), but one thing I find technically superior is the ease with which an RPM can incorporate multiple sources and multiple patches -- this means it's very easy to take a Red Hat package, which contains pristine, original source + patches, and add my own local patches leaving the RH patches in their own "pristine" state. This is harder to do in dpkg -- requires some slight-of-hand at least.
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.
The FIRST machine takes about a day. After that you can build a stage3 ISO for your platform (the only one provided is i686, which will suit most people's needs anyway) which will give you a fully functional gentoo system. Then you can install all the packages you need as binaries built on other systems, as long as they have the same architecture, or a subset (IE, you can run the i386 binaries on your i686 or whatever, but K6 binaries won't run on your i686, or vice versa.)
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
I don't remember needing any slight of hand to do this. apt-get source foo, gets the pristime source and the patches. Copy the patched source dir, make my changes, and diff against the original patched source dir. There i go. Later, get the upgraded version (apt-get source foo automatically only downloads the new diffs, using the old upstream sources (unless, of course, it's a new upstream version)), apply the patch, and there i go again.
If you don't want to use apt-get, download the .tar.gz, .diff.gz, and .dsc files by hand and dpkg-source the .dsc to have it unpack for you. Or do it by hand with standard tools, you'll just have to remember to chmod +x debian/rules that way.
I'm having a great deal of trouble seeing your technical superiority here. The only possibility i see here is if rpm would automatically try to apply my patch after applying the distro's patches, which likely as not is going to fail anyway. Please explain.
--
perl -e'$_=shift;die eval' '"$^X $0\047\$_=shift;die eval\047 \047$_\047"' at -e line 1.
update-menus is in the "menu" package. Once, I forgot to install it, and I had a terrible time trying to figure out why my menus were all horrible!
It usually gets installed in the installation process, unless you're trying to do something weird, like doing the initial install with apt-get instead of dselect.
They who would give up an essential liberty for temporary security, deserve neither liberty or security
It's really not that hard to figure out:
/usr/src/redhat/RPMS).
/usr/src/redhat
rpm --rebuild whatever.srpm
Your shiny new binary RPM(s) will be in whatever the system path is for RPM (on Red Hat it's
Or alternately, you can
rpm -i whatever.srpm
cd
rpm -ba SPECS/whatever.spec
And the binary RPMs will end up in the same place. Plus with that method is you can edit the spec file for customization.
Most people who gripe about RPMs being too hard probably have never looked at the spec files before - all they are is some meta information and a shell script that builds the program. Building from scratch may be hairy for a new user, but customizing an existing package is REALLY easy; usually it's just a matter of looking for a line starting with "./configure" and adding the options you want after that.
Why go through the trouble when you could do it from source? It is much much easier for replicated installs, you don't have to worry about stray files lying all over the place, its easy to tag files as being configuration so they don't get overwritten, etc, etc.
Matt
The problem is not the filesystem. Only users uncertain about the FileSystem Hierarchy Standard or the basis of the POSIX layout could make that mistake. Once you start installing your own files, you'll find most of them goto /usr/local/share, which, for a Windows, is much the equivelant of C:/Program%20Files.
The problem with RPMs comes out of the libraries used by the individual compiler. The most noticeable of these is when an unsuspecting regular GNOME user tries to install a binary constructed by a Ximian GNOME user. Most often when you're told by your package management utility that the particular package has a dependency issue, over fifty percent of the time, I would bet, it's really complaining about a library someone else has that you don't, and the remainder is typically a particular application it was designed to use. If you installed from sources, you would see, and I'm saying from experience, around 85% of these problems dissipate. A large part of this in thanks to considerate programmers who put the time to write alternative configure lines for the to-be-abstracted make file.
If
Ditto on make uninstall too, oh, and don't do the && rm -rf if you think you're going to use make uninstall.
For all other questions about POSIX, feel free to pickup this handy guide
For anyone else with actual standards questions, my email still works (just in case those of you who still care about standards, both of you, still want some guidance).
"Yeah...it was the numbers that were irrational, not the murderous cult of vegetarians...." -- Hippasus of Metapontum