Provides does not work if there is a package with the same name

[Jeff Johnson]

tracker

[Denis Silakov (dsilakov)]

Marked as high priority in the context of Mandriva. But the actual issue is in urpmi which should be fixed by now.

[Jeff Johnson (n3npq)]

Agreed.

FYI (as context):

1) All *.rpm packages have
      Provides: N = E:V-R
(and with Disttag/Distepoch iirc on Mandriva) since forever.
So the bug report as written cannot possibly be an RPM bug
(or there would be zillions of bug reports).

2) When "compatibility" (like in texlive) or the kernel (used everywhere)
is involved, then the dependency assertion markup becomes complex.
E.g. the kernel has always tried to avoid adding a Release: in dependency
assertions for upgrade generality. The problem there is that there is a missing
value in the R: part of the assertion that tend to look like:
     Provides: kernel = V
(note no R) and the semantic implemented in rpm is this
     Missing values in a {E,V,R} tuple are semantically interpreted as
     "all possible" or "every possible" value. This behavior isn't what
     naive users are expecting (they expect rpm to just skip part of a comparison
     when a value is missing)

3) when patterns are involved through filtering (as in the "fix"), then
there is the risk that URPMI and RPM will have different behaviors because
they are driven by different assertions: the filtering introduces a risk
of incompatibilities that isn't being explicitly tested and is not well
understood.

[devzero2000 (pinto-elia)]

Dunno if this should be high importance.
Is it a bug or a rfe, which have already been discussed several times in the past ? What might be the implications of a different behavior?

[Jeff Johnson (n3npq)]

There are (at least) two behaviors possible with missing values.
There is no way to please everyone.

There are large implications of changing the behavior associated with missing values.