rpmlint and Obsoletes: loops

Mike A. Harris mharris at mharris.ca
Tue Jul 25 06:55:08 UTC 2006


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.




More information about the fedora-devel-list mailing list