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.
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, conventionally defined.
the returned boolean value is arbitrarily/
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.