RPM building section of RHL's developer guide

[Jeff Johnson]

On Wed, Jul 23, 2003 at 06:35:00PM -1000, Warren Togami wrote:
> > 
> > 5) "The package may obsolete itself"... I really don't get that one!
> 
> When we hear the answer to this, can we have links from the RHLP page to
> more detailed information describing "why" and examples where it is
> used?
> 
> Can we Wiki this? =)
> 

Every package obsoletes (i.e. erases) itself when using --upgrade.

Obsoletes: is commonly used to get rid of a differently named but otherwise
nearly identical package. In order to resolve dependencies, the new package
often carries a Provides:. So what a packager sees is
	Name: newfoo
	...
	Obsoletes: oldfoo
	Provides: oldfoo
leading to a confusion based on (from user POV) newfoo == oldfoo interpretation.

The only other case I can think of where a packager might consider adding
	Name: foo
	...
	Obsoletes: foo
is to attempt to get rid of other copies of packages if rpm is
invoked with --install. Not gonna work, doesn't afaik, as the
promise of --install is
	No information will ever be erased if invoked with --install.
There's enough conflicting features and policies in rpm that it wouldn't
surprise me to hear about some exotic corner case, but that's a bug imho.

> > 13) "If a newer RPM does not have a binary package that the older
> > SRPMS
> >     produced, the binary package not produced anymore must be
> > specified
> >     with the Obsoletes: option in the new spec file."
> >     I would also add something about encouraging to always use
> > versions
> >     with "Obsoletes:" in order to avoid many kind of future issues
> > when
> >     re-introducing packages for example.
> > 
> > Also, there is no mention of "Epoch:" usage, not even a quick note to
> > suggest not introducing any apart from when it's really the last
> > resort. I
> > guess people may want to stay out of the endless discussion for as
> > long as
> > possible ;-)
> > IIRC, I think I read someone mentioning somewhere that a list of
> > current
> > packages with full "n-e-v-r" would be maintained. With the current
> > implementation of epoch handling in rpm >= 4.2.1, this will become a
> > necessity when depending on specific versions of certain packages.
> 
> Responding to this in a new thread.  Preparing flame retardant suit.
> 

Current behavior in rpm-4.2.1 (and all future versions of rpm) is
	A missing (i.e. unsepcified) Epoch: is exactly equivalent to Epoch: 0.

Whether you choose to make the Epoch: explicit is a matter of style, the
version comparison in rpm is now deterministic, the same answer is returned
every time.

I'd suggest that broken packages (i.e. missing Epoch: is needed) are more
easily handled with
	rpm -Va --nofiles --dbpath /usr/lib/rpmdb/i386-redhat-linux/redhat/
i.e. verify that the dependencies of each package are satisfied within
the universe of packages contained in, say, the rpmdb-redhat package for
the distro, becuase
	a) missing Epoch: is just a special case of a more general problem,
	dependency closure for a collection of packages called a distro.
	a) closure on dependencies cannot be easily detected by a packager,
	but is trivial (and necessary) to check by a distro release manager.

(aside) I'd like to add the closure check to rpmbuild, what stops me is
that noone is willing to figger means to maintain the equivalent of a
rpmdb-redhat package incrementally. Without that, it's premature to
check for dependency closure in rpmbuild. So the immediate problem is
to establish the need of creating a rpmdb-redhat database so that the
tools necessary to do the job can start being written.

73 de Jeff

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