foo vs. foo+
Ville Skyttä
ville.skytta at iki.fi
Sat Jul 21 10:33:06 UTC 2007
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.
More information about the Fedora-maintainers
mailing list