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
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
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
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
> produced, the binary package not produced anymore must be
> with the Obsoletes: option in the new spec file."
> I would also add something about encouraging to always use
> with "Obsoletes:" in order to avoid many kind of future issues
> 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
> 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
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
Chapel Hill, NC