my thoughts on package management

[Robert LeBlanc]

At 02:14 2003/07/23, Ali-Reza Anghaie wrote:
>On Wednesday 23 July 2003 05:00, Robert LeBlanc wrote:
>
> > 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
>
>And your vendor doesn't provide such packages? I'd think for something as
>'enterprise' as DB2 is there are base changes like this that IBM would
>provide the new based-on-RH RPMs.

It's not entirely fair (or effective) to try to pin this issue on the 
vendors, expecting them to solve every conceivable incompatibility 
issue.  In this example I singled out IBM DB2, but the same problem applies 
to many other packages, whether they're closed-source or not.  If I 
download a MySQL (or PHP, or Apache, or...) binary distribution, I have no 
guarantee that it has all the necessary options compiled into it for my 
specific needs.

The problem at the root of all this is that if I ever need to rebuild 
anything from sources, I break the auto-update chain for that package.  The 
fact that I've applied a (developer-defined) customization effectively 
means I can no longer have security updates and bug-fixes applied without 
doing them by hand.  What I'd rather see is a system flexible enough to 
detect (e.g. by reading the equivalent of a config.status file) the 
configuration options that were used to build a package in the first place, 
and then applying these to updated sources--*or*--have it search for a 
binary distribution that was compiled with those specific options enabled.

The latter may in the end be the more feasible option for RH.  Essentially 
have the RPM information itself keep track of what options were used to 
compile the package, so that people who need a set of binaries compiled 
with options X, Y, and J can search on this basis, and make this a 
requirement for any auto-updates.

Robert LeBlanc