On Mon, 2010-08-09 at 18:43 +0300, Anssi Hannula wrote: > Hi all! > > Currently [1], if a package has > Provides: foo = 1.2 > And another package has > Conflicts: foo < 1.2-1 > > The conflict does not trigger, as the releases will be ignored if one of the > compared EVRs does not have it. (mdv bug #55810 [2])
This can be easily fixed by doing: Conflicts: foo <= 1.2-0 > Another similar case is: > A: Provides: foo = 1.2 > B: Requires: foo = 1.2-2 (or >= 1.2-2) > The provides will match, which it IMHO should not be doing. Yeh, you are argue this is wrong ... but I could see how it could happen and be correct too. The better semantics could be argued either way, when there is no release in the provides. The difference though is that current rpm and yum/smart/apt/zypper/etc. all use the current semantics, so arbitrarily changing it has a high incompatibility cost. One way to get what I think you want would be a patch to optionally reject a provides that doesn't have a release, at rpmbuild time. While I can't speak for Panu/etc. ... I don't see why that would be rejected, and you could then fix all your provides to have a release and everything would continue to work. > One solution that may seem obvious at first is making the comparison ignore > releases only if neither has one. However, it would break a situation where > A: Provides: foo = 1.2-5 > B: Requires: foo = 1.2 > > So, in this "requires/conflicts/etc has RPMSENSE_EQUAL on non-released EVR" You can't change the semantics just for '=' operations, or you get insanity like: Requires: foo = 1.2 (matches) Requires: foo >= 1.2 (doesn't match) _______________________________________________ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
