my thoughts on package management

[Robert LeBlanc]

At 00:24 2003/07/23, david paeme wrote:

>RedHat has made an excellent decision when using the RedHat-network
>stuff... the update checker, so no comments there.
>
>But on the other side, people that aren't used to Linux (in general)
>will have problems installing/adding software. The rpm system is nice,
>but If you can't find an rpm that's compiled for your exact system,
>you're in trouble. And let's not forget the infamous dependancy hell!
>
>
>So why not use apt-like system (I'll call it apt from now on)?

This is an improvement that I'd like to see, yes, essentially a "smarter" 
package manager with an awareness of prerequisites, where to find them, and 
how to install them.  A next-generation RPM, effectively :)

On the other hand, I have a long-standing problem with RPMs and the 
updating system.  While it's quite useful for workstation installations 
(where almost all packages are pre-compiled with suitable default options), 
it's all but useless on server installations, where custom configurations 
are common.

As a case in point, if I happen to use IBM DB2 as my database of choice (or 
necessity) on a given server, I'll end up having to (re)build packages like 
PHP from sources in order to configure --with-ibm-db2 or somesuch.  The 
RPM-based PHP distributions won't have been compiled with that option 
(though they may have MySQL support compiled in), so there's no way around 
building from sources in most cases.  This not only defeats the purpose of 
RPMs for these applications, it also makes it impossible to use the 
automated updating features of the RH network, since that system relies on 
a registry of installed binary RPMs.  If I built PHP 4.3.2 from sources and 
the up2date system saw that I had a previously-installed PHP 4.3.2 binary 
RPM installation, it might well upgrade me to the PHP 4.3.3 binary RPM, 
overwriting my custom build.

What I'd like to see in RPMs for server packages is something like dynamic 
compilation based on some checkboxes or command-line flags that describe 
the options to autoconf.  Essentially a higher-level interface to 
./configure, which could be used to build a custom installation of the 
package, and store those settings (e.g. from config.status) so that later 
the up2date process could use those to properly build future versions 
without breaking the existing installation.  If the configuration options 
are not backward-compatible, have up2date simply download the updated 
package and flag it for the administrator to deal with manually.

If none of this is feasible, then at least consider compiling as many 
available options as possible into the binary distributions you package 
into RPMs, so that custom recompilations (which break up2date) won't be 
necessary in as many cases.  Sure, this will result in larger, more bloated 
binaries, but at least they'll have all the optional support features 
built-in, so that there should be no need to rebuild the packages from 
sources later, even if you switch from MySQL to DB2, or something 
similar.  Think of the way the installation kernel contains driver support 
for almost everything, to ensure that almost all hardware will be able to 
run the installation.  If you're going to package binary distributions of 
applications in an RPM, and you want that to be automatically update-able, 
you'll have the most success when people are able to use that package 
"as-is", without having to make custom builds for themselves.

Robert LeBlanc