I've enjoyed reading the previous thread about differing package management
options and wanted to add a few comments about RPM. I have used many different
package management tools on Solaris, AIX, FreeBSD, and just about every
version of Linux since downloading floppies for a base install back somewhere
in 94. I have also built Linux boxes by piecing together a kernel, libc,
busybox, etc.., to the point of writing my own rc scripts for bringup.
RPM has changed significantly since it was first introduced. Many of the
complaints about RPM are really only true for the original incarnations.
Initially there were problems with database corruption requiring rebuilds or
kludgey workarounds. Package installations could leave a system broken. This
said, except for non-RPM OS issues (e.g. drive failure, filesystem related
corruption), I haven't had an RPM database issue in over two years.
The biggest complaint about RPM today is "dependency hell". It's infamous
enough that it's instantly recognizable like "blue screen of death."
Dependency hell is not a bug. It's a feature. Seriously. This is RPM doing its
job. It's letting you know that a package requires certain versions of
libraries or needs other packages to work correctly. Imagine if it didn't do
this checking (i.e., you ran a tarball based installation with requirements on
system libraries). The program may run for a while but then you may get a
weird bug. Because the program seems to run you start looking at other things.
Maybe you spend time diagnosing the system itself, maybe even delve into the
code. Believe me, you want the package manager to warn if version dependencies
are not met.
Then there are package dependencies. You want to install one RPM but get an
error that another RPM is required. Or not. Maybe it just gives "libfoo.so.217
required." This is the hell that most people talk about. Admittedly, RPM by
itself can only warn if the dependency is not satisfied. It is up to the
distribution to ensure that package dependencies are complete in the
distribution. Think of RPM as the engine behind the user friendly package
management tools. It allows you to type "yum install ogle_gui" and
automatically get the DVD libraries, ogle, etc.. Mandrake and Suse have
similar tools.
I'll also add that most of the dependency problems I've seen are because of
improper packaging. Some packagers may require a particular package, including
version, rather than having a service satisfied. I.e., you can specify that a
package needs an FTP server rather than ProFTPD 1.2.3. Sometimes one distro
will use a non-standard name such as libfoo123-xxx.rpm because they build a
compatibility library. Moving this package between distributions can cause
problems until those dependencies are properly updated.
Another complaint about RPM is that it's not as well-tuned for the machine as
source-based distributions. Actually, I think it's easier to build using the
RPM system.
One of my favorite features of RPM is that you can package the sources and the
build instructions in a single file. It allows easy specifications of base
directories and build environments. This allows for easy reproducibility.
I.e., three months later if I want to recreate a package I can do so with a
single command. This is vitally important for maintainers and anyone who needs
to support software.
If I have two systems running the same Linux version/distro on different
hardware (e.g., AthlonXP and a '586) I can use the same source package and
build packages for each architecture with two commands. In most cases I'd want
to build on the fast AthlonXP and then deploy only the binaries on the other
machine. This happens regularly for web systems when building Apache and PHP.
For various reasons I keep development tools off my web and email servers. So
I could so "rpmbuild --rebuild --target=athlon some.src.rpm" and "rpmbuild
--rebuild --target=i586 some.src.rpm". I would then have packages specific for
each machine that I could install.
Other package management tools can do the same things. In fact, the difinition
of a package manager probably requires dependency checking and
reproducibility. So it's a matter of personal preference for me and I'm not
implying that other tools cannot do the same thing. About the only feature I
would wish for is easier rollback. Fedora Core 3 and some of the RedHat
Enterprise offerings allow this with varying success so there's hope.
Sorry for the long email.
-- * The Digital Hermit http://www.digitalhermit.com * Unix and Linux Solutions kwan@digitalhermit.com ----------------------------------------------------------------------- This list is provided as an unmoderated internet service by Networked Knowledge Systems (NKS). Views and opinions expressed in messages posted are those of the author and do not necessarily reflect the official policy or position of NKS or any of its employees.
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 20:38:21 EDT