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

[Panu Matilainen]

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

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.

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

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