This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 249991 - Enhancement: option for yum-priorities not to override version info
Enhancement: option for yum-priorities not to override version info
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: yum-utils (Show other bugs)
7
All Linux
low Severity low
: ---
: ---
Assigned To: Seth Vidal
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-29 00:02 EDT by Allen Kistler
Modified: 2007-11-30 17:12 EST (History)
2 users (show)

See Also:
Fixed In Version: 1.1.7-1.fc7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-09-17 23:21:21 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)
priorities.py patch to add check_versions (1.77 KB, patch)
2007-07-29 00:02 EDT, Allen Kistler
no flags Details | Diff

  None (edit)
Description Allen Kistler 2007-07-29 00:02:33 EDT
Description of problem:
yum-priorities allows prioritizing repos, but it also overrides versions.
Although this behavior was the originally intended purpose, it would be nice if
it could handle prioritizing repositories within package versions, allowing
installs/upgrades to newer versions if lower priority repos had such a version.

Version-Release number of selected component (if applicable):
yum-priorities-1.0.3-1.el5
yum-priorities-1.1.5-1.fc7

How reproducible:
Always

Steps to Reproduce:
1. set local repos to a higher priority than remote repos
  
Actual results:
"yum list available" never lists versions newer than the local one.

Expected results:
Desired result is an option to allow seeing newer remote versions, while
enforcing a higher priority for local repos for same-versioned packages
(especially when working with rhn).

Additional info:
See https://devel.linux.duke.edu/bugzilla/show_bug.cgi?id=586 (which ends with
"won't fix this.  if you want this implemented - use a plugin.")

I've attached a patch for the priorities.py plugin which does what I want (and
maybe a few others, judging by assorted posts I saw while looking for a
ready-made solution).

The patch defines a new config parameter for yum-priorities (declared as v0.04
in the file itself).  If the user enters "check_versions=1" in the plugin config
file, then the plugin respects versions (including epoch and release). 
Otherwise it behaves as before.
Comment 1 Allen Kistler 2007-07-29 00:02:33 EDT
Created attachment 160181 [details]
priorities.py patch to add check_versions
Comment 2 Tim Lauridsen 2007-07-29 02:18:08 EDT
Look good to me, i have added it to upstream, it will be available in yum-utils
1.1.7
Comment 3 Tim Lauridsen 2007-07-29 02:22:18 EDT
Hi Daniel

Do it look ok to you ?

Comment 4 Daniel de Kok 2007-07-29 03:19:56 EDT
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.
Comment 5 Tim Lauridsen 2007-07-29 08:49:00 EDT
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



Comment 6 Allen Kistler 2007-07-29 14:21:03 EDT
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?
Comment 7 Daniel de Kok 2007-07-29 16:59:27 EDT
"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.
Comment 8 Allen Kistler 2007-07-29 17:22:54 EDT
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....
Comment 9 Fedora Update System 2007-09-10 12:51:52 EDT
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.
Comment 10 Fedora Update System 2007-09-17 23:21:15 EDT
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.

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