On Wed, Jul 23, 2003 at 06:35:00PM -1000, Warren Togami wrote:
- "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.
- "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@redhat.com (jbj@jbj.org) Chapel Hill, NC