Bug 249991
Summary: | Enhancement: option for yum-priorities not to override version info | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Allen Kistler <ackistler> | ||||
Component: | yum-utils | Assignee: | Seth Vidal <skvidal> | ||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | low | Docs Contact: | |||||
Priority: | low | ||||||
Version: | 7 | CC: | danieldk, tim.lauridsen | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | 1.1.7-1.fc7 | Doc Type: | Bug Fix | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2007-09-18 03:21:21 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Allen Kistler
2007-07-29 04:02:33 UTC
Created attachment 160181 [details]
priorities.py patch to add check_versions
Look good to me, i have added it to upstream, it will be available in yum-utils 1.1.7 Hi Daniel Do it look ok to you ? I like the idea, but I'd like to see the following things handled/thought out better: - Obsoletes, though the approach outlined below doesn't require any changes to the obsolete handling. - Handling of multiple repos. Consider the following situation: local 1 RHN 2 RPMForge 20 With this configuration, this plugin will not correctly protect local/RHN repos from being protected from RPMForge packages. That's a showstopper for me. A quick idea: practically local and RHN have the same priority, but if the package versions are the same you just want to give the local repo a higher priority. So, what about an optional "subpriority" that could be specified in the following manner: [local] priority=1:1 [rhn] priority=1:2 [rpmforge] priority=20 So, wrapped up the "package elimination repo looping" would look like this: - If the package is in pkg_priorities, and the priority of the repo is lower than the highest priority found for the package, throw out the package. - Else, check whether the package from this repo is the latest version (for the priority) and the highest "subpriority". If one of these conditions is not true, throw it out. - Check obsoletes. I think with this approach the obsolete handling does not need change as part of this improvement. We'd just need to extend the priority dict entries a bit to have more information than just the priority. if local has foo-1.0 and rpmforge has foo-2.0, and then check_version is set, then foo-2.0 will be installed, then the lower priority wins, it is only when both repo has foo-2.0 that local will win. We dont want that. The lower priority must always win even when a higher version is available i another repo. I will revert the patch. If someone want to install the highest available version of a package, they can just use yum --disableplugin=priorites install foo (yum >= 3.2.1) About the sub priority, will this not give the same result ?? [local] priority=1 [rhn] priority=2 [rpmforge] priority=20 My intention with the check_versions parameter was purposefully to change the behavior from "priorities always win" to "versions always win, but from the lowest priority number." I know it's different from the original purpose, but the user can pick what behavior he wants with the parameter. Example: repo1 with priority=1 has pkg1-1.0 and pkg2-1.0 repo2 with priority=2 has pkg1-1.0 and pkg2-1.1 repo3 with priority=3 has pkg1-1.0 and pkg2-1.1 So if I want pkg1, yum gets it from repo1 (highest pri for highest ver) But if I want pkg2, yum gets it from repo2 (highest pri for highest ver) The hassle with disabling priorities to get the latest version is that you'd have to "yum list available" with priorities enabled and disabled, then do a diff to see if there's a version you want, except with priorities disabled you'd have to do it from each repo individually to see which ones have it and which ones don't (if you still want to rank favored ones over unfavored ones). That's a lot of pain. The subpriorities idea was perhaps heading to a mixture of the two behaviors, I think, where the highest version package "within" a priority wins, but lower priority numbers still always win over higher priority numbers. If two repos have the same version "within" a priority, then the lower subpriority wins. (So assiging rhn a priority of 2 isn't the same as 1.2, because 2 always loses to 1, but 1.2 wins over 1.1 if 1.2 has a higher version, otherwise 1.1 wins over 1.2 if 1.1 and 1.2 have the same version, if I understand correctly.) The idea gives everyone what they want, but... rhn repos are added by the rhn plugin, not a .repo in yum.repos.d, so they get priority 99. With the current priorities.py, if there's a newer version of a package in rhn, rhn always loses if priorities are enabled. If priorities are disabled, yum could (i.e., does for me) ignore local repos and hit up rhn when it shouldn't, leading to the pain of listing available for each repo and comparing "by hand" for versions. (Argh) Perhaps there could be a plugin parameter, default_priority, with a default value of 99. By assiging it a value of 1.2 (or whatever the user chooses), that's the priority that rhn repos (or any repo without an explicit assignment) would get, otherwise repos would get the value assigned in their .repo files. Proposal: check_versions is gone default_priority is in with a default value of 99 higher versions (epoch/ver/rel) within a priority win over lower versions (yum main actually sorts that part out) same versions within a priority use "subpriority" to decide priority same name.arch across priorities uses priority to decide priority Thoughts? "My intention with the check_versions parameter was purposefully to change the behavior from "priorities always win" to "versions always win, but from the lowest priority number." In my opinion that is clearly out of the scope of priorities and should belong to a separate plugin. "The subpriorities idea was perhaps heading to a mixture of the two behaviors, I think, where the highest version package "within" a priority wins, but lower priority numbers still always win over higher priority numbers." Correct. "Perhaps there could be a plugin parameter, default_priority, with a default value of 99. By assiging it a value of 1.2 (or whatever the user chooses), that's the priority that rhn repos (or any repo without an explicit assignment) would get, otherwise repos would get the value assigned in their .repo files." I do not see the use of such tunable. 99 is just a nice arbitrary point, setting it to something else doesn't really matter. What matters is how priorities of repos with 'priority=n' are set in relation to 99. If subpriorities were added, it could just be set to, say 'priority=99,subpriority=99', which really doesn't differ from setting it to 'priority=1,subpriority=2'. "Proposal:" I still like the subpriority idea, but after some thought I think it would be better to put that functionality in a separate plugin. In that manner protectbase users or users of no protection plugins can also benefit. I'll look at protectbase to see how it would be affected by changes in priorities. In the meantime (1) I know what works for me and (2) I'll keep looking to see if I can find a logical way to fit it in for others who are interested. Closing.... yum-utils-1.1.7-1.fc7 has been pushed to the Fedora 7 testing repository. If problems still persist, please make note of it in this bug report. yum-utils-1.1.7-1.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report. |