Bug 460781 - RFE: process Provides versions with "yum install virtualpackage"
RFE: process Provides versions with "yum install virtualpackage"
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Seth Vidal
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-08-31 15:10 EDT by Ville Skyttä
Modified: 2014-01-21 18:06 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-08-31 17:48:08 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ville Skyttä 2008-08-31 15:10:46 EDT
yum 3.2.19 does not appear to process Provides versions, at least with "yum install virtualpackage".

One example from F-9 (x86_64 but shouldn't matter):

yum resolvedep java-javadoc returns java-1.5.0-gcj-javadoc (which has Provides: java-javadoc = 1.5.0.0-21.fc9) even though java-1.6.0-openjdk-javadoc (which has Provides: java-javadoc = 1:1.6.0.0-0.16.b09.fc9) would also be in repo.

For consistency with name based non-Provides stuff, it'd be nice to process the possibly present versions of requested Provides before falling back to name length comparisons.
Comment 1 James Antill 2008-08-31 17:48:08 EDT
> 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.
Comment 2 Ville Skyttä 2008-09-01 01:49:49 EDT
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.
Comment 3 James Antill 2008-09-02 01:15:32 EDT
> 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'
Comment 4 Ville Skyttä 2008-09-02 02:17:50 EDT
(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.
Comment 5 James Antill 2008-09-02 10:10:40 EDT
> 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.

Note You need to log in before you can comment on or make changes to this bug.