my thoughts on package management

[Jeff Johnson]

On Wed, Jul 23, 2003 at 12:20:38PM -0700, Robert LeBlanc wrote:
> 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.

There are two problems here:
	1) how the build system is set up.
	2) how the package was built.

The build system for RHL is setup by using build dependencies for all but
a handful of packages like gcc and make.

How the package was built is encoded in the spec file, and rpm by design
guarantees that each and every rpm started from a spec file, virgin sources,
etc and ran to completion in some build system.

Yes there is no explicit config.status, basically because there is no need
if you are using RHL packages, or custom modifications of RHL packages,
or simple additions to RHL distros.

73 de Jeff

-- 
Jeff Johnson	ARS N3NPQ
jbj at redhat.com (jbj at jbj.org)
Chapel Hill, NC