Panu Matilainen kirjoitti keskiviikko, 11. elokuuta 2010 12:56:05:
> On Mon, 9 Aug 2010, 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])
>
> Right, this looks plain wrong or at least rather strange, even if its easy
> to avoid.
>
> > 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.
>
> This is long-standing behavior which I always thought of as an intentional
> "feature", irritating as it can be (one famous example of this was RH
> kernels having "Provides: kernel = %{version}", forcing kernel module
> packagers and such to use obscure file paths for requires for a specific
> version). Which is not to say I couldn't be convinced otherwise, but like
> James points out these rules are copied outside (and even inside) rpm in
> numerous places, and shouldn't be changed lightly. Doesn't mean it
> shouldn't be discussed though...
I'm not sure how the "Provides: kernel = %version" case is related here. Or do
you mean stuff like "Requires: kernel = 2.6.2-2" should work even if the
actual provide is just "kernel = 2.6.2"?
> This is actually eeriely similar to the "epoch promotion" behavior,
> and the above cases could be cured with a similar treatment: define
> non-existing release to be exactly the same as zero release.
Indeed.
> > 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
>
> ...and the "no release means zero release" would break this too, unless
> the implicit zero release is only applied to provides. But
>
> > So, in this "requires/conflicts/etc has RPMSENSE_EQUAL on non-released
> > EVR" case we actually do not want to compare the releases. So, if we
> > restrict that case out, we get the attached patch
> > rpm-nonreleased-compare.patch (which I based on [3] which comes from
> > Jeff Johnson and Per Øyvind Karlsen, just removing cosmetic changes and
> > changes relating to epoch handling).
> >
> > However, in addition to changing the seemingly wrong behaviour of the
> > first case described in the beginning of this message, the following
> > noteworthy case is also changed:
> > A: Provides: foo = 1.2-1
> > B: Requires: foo > 1.2
> > Previously this didn't match, after the patch this matches.
> > IMHO this change in behaviour is not wanted, so the attached patch rpm-
> > nonreleased-compare-2.patch restricts this case out as well.
>
> Depending on how you look at it, "foo = 1.2-1" not matching "foo > 1.2"
> can seem just as bizarre as the conflicts case not matching.
> "Requires: foo > 1.2" is quite ambiguous.
True, I guess "foo > 1.2" is ambiguous enough that either behaviour could be
considered "correct".
I don't oppose changing it, it was just that this may be more commonly used
and existing packages may depend on it. I checked our repository, and it seems
only around 20 packages use this, though, and it seems like most of them could
rather simply be modified to use >= instead.
One use I case I can see for the current behaviour, though, is a package
conflicting with all future versions of foo when the next version number of
foo is not known and thus >= can't be used.
> > Also, I attach rpm-compare-against-norelease3.patch (that I just came up
> > with while writing this) which is AFAICS functionally equivalent to
> > rpm-nonrelease- compare-2.patch, but instead of modifying parseEVR() to
> > return "" for nonexistent releases, it treats empty release of a provide
> > as "" for a comparison in case the conflict/require/etc has a release.
> >
> > I guess something like rpm-nonrelease-compare-2.patch or
> > rpm-compare-against- norelease3.patch should be applied (after proper
> > testing, of course), unless we consider the original issues not-a-bug. I
> > don't know which approach is preferable (or if neither is, or if the
> > first patch with the caveat is), as I'm not too familiar with the rpm
> > internals.
> >
> > Please comment.
>
> No comment on the implementation details for now, except that
> rpmdsCompare() is by no means the only place inside rpm containing version
> comparison code, there are at least 2-3 other places that would also need
> adjusting. Not to mention all the other tools. Just for an idea how
> expensive these kind of changes can be: the way epoch comparisons are made
> was changed in ~2002, and I'm *still* seeing fallout from that. IIRC the
> last fix for the "no epoch is equivalent to zero epoch" behavior inside
> rpm itself went in as recently as late 2008.
>
> So no ACK or NAK for now, discussion on the subject is welcome though.
>
> - Panu -
--
Anssi Hannula
_______________________________________________
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
