foo vs. foo+

[Ville Skyttä]

On Saturday 21 July 2007, Florian La Roche wrote:
> On Sat, Jul 21, 2007 at 12:50:35PM +0300, Ville Skyttä wrote:
> > On Saturday 21 July 2007, Patrice Dumas wrote:
> > > On Sat, Jul 21, 2007 at 04:15:19AM +0200, Christoph Wickert wrote:
> > > > Ok so far, but foo+ also needs a "Provides: foo", and I wonder if is
> > > >   Provides: foo
> > > >   Conflicts: foo
> > > > really is a good idea. And can/should we use versioned Provides:
> > > > here?
> > >
> > > Unless I am wrong, yum (rpm) won't care about versioned Provides:, and
> > > replace foo+ with foo (I had such issues with libnet10/libnet).
> >
> > Do you have a test case available where rpm/yum ignores the version?
>
> For "Provides: foo" and "Requires: foo >= 1.0" the version information
> is just ignored and this always matches.

I wouldn't say anything is ignored there; I tend to think of Provides: foo 
as "Provides foo, all versions of it".  But perhaps that's just playing with 
words.  Anyway it does demonstrate problems with unversioned Provides and 
friends.

> I've written a small test, so that all such cases can be listed and they
> can get screened for real problem cases. Output for the current
> Fedora-devel tree looks like:
[...]
> So this is mostly hit by perl rpms and then a few others. Shouldn't be a
> big thing to clean up overall.

I suspect the majority of the perl ones are affected because something in the 
module's contents outsmarts rpmbuild's automagic Provides extraction and 
should ideally be fixed there to the extent possible instead of patching the 
packages.  For example General.pm in perl-Config-General has:

    package Config::General;
    [...]
    $Config::General::VERSION = 2.33;

rpmbuild doesn't extract the version from a fully qualified notation like this 
one.  I submitted a patch for that and some other cases a long time ago 
(#61797), maybe it or parts of it should be resurrected.