[Bug 633208] Re: comparisons without release

[Jeff Johnson]

This bug was orignally identified by Mancoosi WP5 last December.

The bug is that Conflicts: assertions are not correctly verified when
the Release field is missing.

The impact is small because most RPM based distros tend
not to use Conflicts: assertions. The fact that the issue has
NEVER been reported or noticed (the bug has existed since rpm-3.0.2)
also indicates that the problem has low impact.

Adding an explicit version (and removing the missing value) is
likely the easiest solution because the behavior for Conflicts:
comparison is correct for all versions of RPM.

There are multiple patches that fix the problem attached to the Mandriva
bug.

Since the root cause is behavior of a Conflicts: assertion with a missing value,
the returned boolean value is arbitrarily/conventionally defined.

The patch from @rpm5.org if/when the necessary QA to identify affected packages
across multiple distros can be done. I personally think the problem is minor
(because there is a workaround by adding an explicit release to the comparison)
and becuase its more important to be bug-compatible with existing behavor
than to be logically correct. Behavior with missing values for any assertion checker
is always conventionally defined.

** Changed in: rpm
   Importance: Medium => Low

** Changed in: rpm
       Status: Confirmed => Triaged

-- 
comparisons without release
https://bugs.launchpad.net/bugs/633208
You received this bug notification because you are subscribed to PLD
Linux.

Status in rpm package manager: Triaged
Status in Ubuntu: New
Status in CentOS: New
Status in Mandriva Linux: Confirmed
Status in PLD Linux Distribution: New

Bug description:
Posted from Anssi Hannula on rpm maint mailing list (http://www.mail-archive.com/rpm-maint@lists.rpm.org/msg01611.html)

*****************************

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

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.

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

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.

Note that all the attached patches are untested for now. The original patch
[3] was tested with 4.6.0 at the time and it seemed to function expectedly
(i.e. only with the caveat described above).

[1] didn't confirm with git master, but the code seems the same
[2] https://qa.mandriva.com/show_bug.cgi?id=55810
[3] http://kenobi.mandriva.com/~anssi/rpm-4.6.0-rpmvercmp-handle-missing-
values_1.patch