Michael Schwendt wrote:
On Tue, 25 Jan 2005 08:53:17 -0500, seth vidal wrote:
Obsoletes should be used when a package changes name. Not when someoneSounds interesting. On the other hand, maybe we could do it manually (from a packager's point of view) : if you package library foo, and you know that version 0.1 is not supported anymore (noone knows that better than you since you maintain it), you can add an Obsoletes tag to your libfoo5 package, and force the removal. Would that solve Jeff's issue ?
thinks a new version gets rid of an old version.
Where are such strict semantics of the "Obsoletes" field defined?
The strict semantics are hard coded in up2date and yum, for starters, hard coded
is strict enough for me.
Isn't it rather free to use? As in "we don't need that package
any longer, it's obsolete and can be erased"?
Sure, feel free to do whatever. Without well defined packaging guidelines, packages will break, but reports will be filed, packages will be fixed and, life as usual.
If, for instance, functionality of one package is supplied by another
package, that's not a rename, but a relocation of package
capabilities. Package "foo" would "Obsoletes: bar <= 1.0". If an old
library API/ABI is not used anymore and hence considered obsolete, a
new version of the library could "Obsolete: libfoo <= 0.9" just fine.
Obsoletes: has changed to erase a package that contains a virtual provides for
exactly this reason.
In fact, dependency comparisons don't use package NEVR at all several years now
in order to handle functionality shifts that are not package renames.
73 de Jeff
