Conflicts: dependencies without release misfire

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.

From the one issue reported as a result of fixing this in Mandriva Linux, it in turn revealed a flaw in the packaging relying on what's generally considered as unexpected behaviour, which should rather be fixed in stead.
These cases are obviously few, easy to trigger and generally a result of "wrong" packaging practice that's both easy to fix and should be fixed.

For the issue that revealed the bug, it's not an issue easy to find by triggering it, and it's also a result of what would be consistent and the expected behaviour not behaving that way, which in turn makes these situations more plausible and easier hidden.

Analyzing metadata such as synthesis.hdlist.cz for whole distribution to fully investigate wouldn't hurt, and should probably be easy to do. IIRC we have some tools for these things in Mandriva Linux already, using the perl bindings also..
TODO++

I was looking at our rpm-4.5 branch but unfortunately the changes do not apply cleanly. I'm not up to date with rpm internals so will leave it to someone else to fix this issue in PLD.

Grrr, did the duplication the wrong way.

So what to do for rpm5?
Okay with the following change, or should I push it under an #ifdef?

--- rpmdb/rpmevr.c~ 2010-03-06 17:20:46.000000000 +0100
+++ rpmdb/rpmevr.c 2010-10-15 20:21:28.120003324 +0200
@@ -277,6 +277,10 @@ assert(b->F[RPMEVR_D] != NULL);

     for (s = rpmEVRorder(); *s != '\0'; s++) {
        int ix;
+ if(*s == 'R' && (b->Flags & (~RPMSENSE_GREATER & RPMSENSE_EQUAL))
+ && *(b->F[RPMEVR_R]) == '\0')
+ break;
+
        switch ((int)*s) {
        default: continue; /*@notreached@*/ /*@switchbreak@*/break;
        case 'E': ix = RPMEVR_E; /*@switchbreak@*/break;

Under an #ifdef RPM_VENDOR_MANDRIVA please ... its still not
clear (in general) whether "bug compatible" behavior or "logical/sensible behavior"
is preferred. This would _NOT_ be the first bug in RPM that gets
stuck into the concrete.

Personally, I'd like to just get through bug fixing (of the "logical/sensible" persuasion)
and get on to adding dependency ranges, and attribute qualifiers, and trigger filtering,
and file versioning, and ... enhancements.