Bug 460781

> For consistency with name based non-Provides stuff

 That's not how "name based non-Provides" stuff works. We pick a package, then we get the latest version of it (if nothing is specified explicitly). That's how everything works.

 Also, this request isn't a good change to make IMO because:

1. Not everything has versioned provides.

2. Versioned provides can be one of EQ, LT, LE, GT, GE. Only the first makes any sense to do the magic you suggest. Hell java-1.5.0-gcj-javadoc versioned provides: "java-1.4.2-gcj-compat-javadoc > 1.4.2.0-40jpp.111".

...there has been some talk of doing something which could be used to give hints to the package manager about which of several choices is better. So that "yum install smtpd" does the "best" thing. Feel free to speak with people about moving that forwards, as that could also "solve" this case.

Shrug, I understand how things work at the moment, this RFE was about changing it to be more intuitive.  I also don't see a problem with missing versions or LT, GT etc things, code for comparing those to specific versions, no versions and LT, GT and friends must already exist somewhere as it's required for proper Requires/Provides processing.

> Shrug, I understand how things work at the moment, 
> this RFE was about changing it to be more intuitive.

 No, this would happen to dtrt. in your specific case ... that doesn't mean it's "more intuitive" or even be better in general.

> I also don't see a problem with missing versions or
> LT, GT etc things, code for comparing those to specific versions [...]
> must already exist somewhere as [...]

 That code doesn't have to exist, AFAIK, and so someone would have to write it and an "intuitive" result would have to be found for:

 "pkgA provides XYZ >= 1.2"
 "pkgB provides XYZ < 1.4"
 "pkgC provides XYZ = 1.3"

...again, I appreciate that this change would make your case better ... but it's far from obvious that it's the "right" thing to do.
 As a quick fix creating one or more "java" groups seems like the obvious solution. For a better long term. fix, again see my suggestion to speak to people about solving the generic problem of 'yum doesn't pick the "best" provider'

(In reply to comment #3)
>  That code doesn't have to exist, AFAIK,

Hm, I must be missing something then: if that code or major parts of it does not exist, how does yum know which of the below to match if some package has for example "Requires: XYZ = 5.0" or "Requires: XYZ = 1.1" or "Obsoletes: XYZ < 1.3.5"?

> and so someone would have to write it
> and an "intuitive" result would have to be found for:
> 
>  "pkgA provides XYZ >= 1.2"
>  "pkgB provides XYZ < 1.4"
>  "pkgC provides XYZ = 1.3"
> 
> ...again, I appreciate that this change would make your case better ... but
> it's far from obvious that it's the "right" thing to do.

Let me try to explain why to me it is obvious: in the context of "give me the newest XYZ", the answer would be pkgA.  pkgB is always older than 1.4, pkgC is always exactly 1.3, pkgA is anything newer than or exactly 1.2 (i.e. its upper limit is the maximum value that can be expressed in rpm EVR's).  There are of course scenarios that end up in ties (such as for example provides XYZ >= 1.0 and provides XYZ > 2.0), these should be then resolved with the usual way ties do get resolved.

Thanks for the alternative suggestion, I'll keep an eye on such discussion if it takes place somewhere where I'm subscribed.  I however still think that this functionality inevitably needs to be part of solving the generic problem.

> how does yum know which of the below to match if some package has

 For requires/provides it only needs to know which packages provides satisfy the requires, it does not need to sort them.
 And it's basically the same with conflicts/obsoletes ... all it needs to know is given conflict/obsolete XYZ from pkgA is pkgB covered or not.