[Bug 633208] Re: Conflicts: dependencies without release misfire

[Bug Watch Updater]

** Changed in: mandriva
       Status: Confirmed => Fix Released

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

Title:
  Conflicts: dependencies without release misfire

Status in The Caixa Magica Project:
  New
Status in IDMS Linux:
  New
Status in rpm package manager:
  Triaged
Status in Unity Linux:
  New
Status in Yoper Linux:
  New
Status in “rpm” package in Ubuntu:
  New
Status in CentOS:
  New
Status in Debian GNU/Linux:
  New
Status in Mandriva Linux:
  Fix Released
Status in openSUSE:
  New
Status in PLD Linux Distribution:
  New

Bug description:
  Posted from Anssi Hannula on rpm maint mailing list (http://www.mail-
  archive.com/rpm-maint at 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