Re: my thoughts on package management

[Robert LeBlanc <rjl renaissoft com>]

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

Sorry, but I feel a bit like I've been "talked in circles", here :)  I've 
been describing the problems inherent in "custom modifications of RHL 
packages", namely that any need to rebuild anything from sources (e.g. to 
recompile a package with a different set of configuration options) breaks 
the auto-updating capability for that package.  I'm confused by the last 
sentence of your response, though, which seems to imply that there's no 
problem here at all.  Could you clarify that a bit more?

I confess to being an old-timer, having used Linux since kernel 0.99.12 
when *everything* had to be assembled by hand.  I'm well used to the 
process of downloading a source tarball, configuring and building the 
sources, and installing packages that way.  When RPM came along I was 
initially impressed--package installation was about to become a whole lot 
easier and more streamlined, I thought.  This is certainly true for "out of 
the box" installations, like for mass-deployment on workstations, but for 
servers I've simply determined that RPM and its auto-updating facilities 
are just false hopes--I can't (and therefore don't) use them, as too much 
customization tends to be required for server apps.

The downside of doing everything manually, of course, is that I now have to 
keep abreast of bug and security fixes myself, and apply them all by hand 
to my sources, rebuild them, and reinstall them.  I'd really like the 
convenience of the auto-updating facility--and would find it worth paying 
for--if it could actually work for me.  The fact that it can't unless I 
straightjacket myself with "standard" binary installations is frustrating.

I'd like to see a more flexible, versatile approach in any 
"next-generation" RPM/up2date system, and that's what I'm trying to 
petition for here.  Either a Gentoo-like system that can build applications 
at install time with user-specified options selected, or at least a means 
of making the option set visible somewhere within the RPM package, so that 
when updates are downloaded for those packages the up2date process can 
search for RPMs built with those particular options.  I'm sure there are 
other solutions that would work as well, given a little time and thought, 
and a willingness to make changes on this level.

If, on the other hand, you really feel this is a problem that doesn't 
exist, or one that would require more work to fix than you're willing to 
invest, just say so and I'll shut up.  I'm only trying to help make the 
RPM/up2date system live up to its initial promise, and if indeed you 
believe it's as good as it can get I'll drop the matter and go back to my 
tarballs, or to Gentoo.

Robert LeBlanc