[Rpm-maint] [RFC/PATCH] comparisons without release

[Anssi Hannula]

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