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
Attachment:
pgpZSSozDuUPD.pgp
Description: PGP signature
-- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers
-- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
