foo vs. foo+

[Axel Thimm]

On Sat, Jul 21, 2007 at 01:33:06PM +0300, Ville Skyttä wrote:
> 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).

No, that's a different bug probably. If one of the virtual provides
was a real entity then you trigger another rpm bug that was tagged a
feature (check bugzilla for concurrent python of some sound libs from
ccrma for details, I don't have the bz# handy): It automatically
introduces silent Obsoletes ...

> > > 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.

That were the semantics that were applied to rpm and the versionless
syntax above, Ville's wording strike the specification back then quite
accurately. This was the ancient painful Provides: kernel issue.

E.g. Florian's example is exactly what should not be done.
-- 
Axel.Thimm at ATrpms.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-maintainers/attachments/20070721/3634699c/attachment.sig>