my thoughts on package management

[Jeff Johnson]

On Thu, Jul 24, 2003 at 04:12:47PM -0400, Paul Iadonisi wrote:
> On Thu, Jul 24, 2003 at 12:07:39AM -0700, Robert LeBlanc wrote:
> 
> [snip]
> 
> > 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.
> 
>   To be frank, I think you really are looking for something more like Gentoo.
> Red Hat is doing its best to handle the 95% - 99% use cases.  In my own,
> somewhat biased opinion, I think they do a pretty good job of it.  But I
> have run into similar things that you have (applying a mysql patch to
> sendmail and building the cyrus-sasl-mysql module as two examples).
> 

There's room for moving closer to a Gentoo approach, but typically the
problem revolves around
	a) how to set up a build system
	b) how to use rpmbuild to package

Both a) and b) are simple with a rpm package management domain, but
entirely outside of the scope of rpm if/when you want to do your own
thing differently.

> > 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.
> 
>   Although I don't think anyone at Red Hat is going to tell you 'shut up,'
> I don't think that rpm/up2date has ever included the promise of being able
> to account for custom changes users have made.  Read the section in the release
> notes of the past several releases on the Ximian desktop for evidence of this.

Up2date (and rpm underneath it) depends solely on the concepts (N == name,
E == epoch, V== version, etc)
	a) package N to choose what to compare with.
	b) "newer" as in EVR version comparison.
	c) whether to use rpm for software mgmt at all.

Both a) and b) are quite mangeable for customization. b) in particular
pretty much means that you have to choose a release that is newer than
the RHL starting point, but "older" than any release number that rpm is
likely to choose. This preserves the ability to upgrade, see "vepoch"
in the package building guidelines at http://fedora.us for a perfectly
reasonable rule based release naming scheme that has the right properties.

The other piece that might be needed is to configure up2date to
	Never remove or upgrade this package.
(i.e. because it's customised). Already there, breaks on paradigm shifts,
but Red Hat does it's best to avoid aurprises. Sure there's surprises, NPTL
comes instantly to mind, but there are as few as is humanly possible.

c) is insoluble in general, way outside the scope of rpm package management
as currently implemented.

73 de Jeff

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