Matthias Saou wrote:
Florian La Roche wrote :
One item has just come up the last days within
FC-development: openssh has added to the "Obsoletes:"
lines also the corresponding "Provides:" lines.
End result is that this created an "Obsoletes loop"
where an older openssh-askpass-gnome package obsoletes
a current openssh-askpass and the current openssh-askpass
package also obsoletes openssh-askpass-gnome.
(In more detail this happened via the obsoletes/provides
"ssh-extras".)
This of course does not show up for FC-development where
only the newest packages are in the tree, but it does show
up if you take older repos together with FC-devel packages
(which is normally not a good mixture, but that is
another story).
While it is most times a good idea to add the "Provides:"
lines for all obsoletes as well, we should not just add them
to all of them. Especially not if nobody found them missing
for many years by now.
Something we should keep in mind if we now look more and more
at rpmlint and how it reviews rpm packages.
The solution here is simple : ALWAYS use a version-release for
"Obsoletes:" lines. Period. This would have prevented this problem
from ever existing. Same goes for "Provides:", that way you keep much
more control.
Of course, you won't be able to go fix the old package now... pretty
much like an existing epoch.
I'd like to see the default Fedora rpmlint configuration error on
"Obsoletes:" without a version, and warn on "Provides:" without one
either, if that's not already the case.
Ok, so you have FC5 with a package named "foo-3.5-7" and FC6 with a
package named "bar" which obsoletes it. If we do what you suggest,
then the "bar" package in FC6 would contain:
Obsoletes: foo <= 3.5-7
And if we release an update of foo for FC5, such as foo-3.8-1, then
the FC6 "bar" package no longer obsoletes the "current" foo released
for FC5, and OS upgrade from FC5+updates to FC6 will fail, or at
least result in incorrect final system image after install.
Furthermore, if other packages in FC6 depend on something unique
to bar, and have "Requires: bar", then you have another problem.
Using version-release on Obsoletes makes sense sometimes, but it
does not always make sense, and can in fact cause serious
unexpected issues.
Using version-release with Provides also makes sense sometimes, and
makes no sense other times. It depends on what specifically the
Provides is being added for. Some are there for backward compatibility
when obsoleting something else, while others are there to provide a
virtual package for things to depend on. For virtual packages,
sometimes a sensible "version" or "version-release" is doable in a
useful way, and other times it makes no sense. Some virtual provides
are very intentionally placed in packages to be an implementation
agnostic and version-neutral dependency that other packages can rely
upon. ie: "Xnest", "Xvfb"
There's room for improvement in the packages in the OS, but a solution
like you propose isn't that cut and dried.
--
Mike A. Harris * Open Source Advocate * http://mharris.ca
Proud Canadian.
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
