I went ahead and ran with some of the ideas that were being kicked around for repository scoring/prioritization [1,2] a while back. Patch for yum-2.0.1 is attached (works on the 2.0.x 20030828 daily as well). a "yum -d 4 ..." will show scoring comparisons. $ cd yum-2.0.1; patch -p1 < server-scoring.patch The implementation pretty much follows rules outlined a while back by seth, michael, and others: * Each server section MAY have a "score" attribute. * The score attribute MUST be an integer if specified (full range of integer allowed [+ or -]) * score defaults to 0 when no value is specified. * When a package with the same _name_ exists on more than one server, the package from the highest scoring server (i.e. server with greatest numeric value) is selected. * When a package with the same _name_ exists on more than one server with equivelant scores, package selection falls back on pkgpolicy=[newest|last] logic. So yum should act exactly as it does today when all scores are 0. * When a package is exclude'd from a server, it is not considered in scoring with other servers. Some examples: # yum.conf [main] cachedir=/var/cache/yum debuglevel=4 logfile=/var/log/yum.log pkgpolicy=newest [repo1] name=repo1 baseurl=... exclude=bar # has foo-1.0-1 bar-1.0-1 bling-1.0-1 biz-1.0 # score defaults to 0 [repo2] name=repo2 baseurl=... score=100 # has foo-0.9-5 [repo3] name=repo3 baseurl=... score=-20 # has bar-2.0-1 biz-2.0 [repo4] name=repo1 baseurl=... # has bling-3.0-1 # score defaults to 0 * package "foo" would be drawn from repo2 due to score even though repo1 has newer version. * package "bar" would be drawn from repo3 even though repo1 has higher score because repo1 excludes "bar". * package "bling" would be drawn from repo4 since both repo1 and repo4 have score 0 and repo4 has "newest" version. * package "biz" would be drawn from repo1 even though repo3 has newer version because repo3 has lower score. There are a few kinks that may need to be thought out a bit more. First off, the package's _name_ is the only thing that has to be the same on two repositories to cause a conflict and have scoring kick in. The package's arch is not considered. If repo1 has i386, i586, and i686 versions of a package and repo2 has only an i386 version, and repo2 has a higher score, then only the i386 package from repo2 will be in the list when it comes time to pick a best version by arch. This seems to be correct in most cases but I can also see situations where you might want to do scoring on name/arch conflicts instead of just name conflicts. Taking this a step further, you may want scoring to occur only when all of name/arch/version conflict. Or maybe just name/version. Point is, I'm thinking it might make sense to make this configurable with some kind of scoring policy attribute under main. e.g. scorepolicy=name # default: packages scored when package names conflict. scorepolicy=name,arch # packages scored when package name and arch conflict. scorepolicy=name,arch,version # packages scored when package name, arch, and version (but not # release or epoch) conflict. scorepolicy=name,version # packages scored when package name and version conflict (but not arch). The value would be any combination of the following items: name,version,release,epoch,arch. This would let you control which nvral items cause a scoring conflict. This may be wandering into the realm of too-complexed but it actually seems kind of elegant to me. The other possible issue is that non of this applies to the "locally installed" repository. This can be kind of weird when you have, say, foo-2.0 installed and you modify yum.conf to bump the score of a repository with foo-1.0 so that it has priority over the repository you initially grabbed foo-2.0 from. At this point, you might want yum to show foo-1.0 on a "list updates" but it doesn't because local packages are compared after all scoring is done with "newest" type logic. You would have to erase the locally installed package manually to get yum to show you foo-1.0. Thanks, - Ryan [1] "Repository Prioritization" Thread - Aug 2, 2003 https://lists.dulug.duke.edu/pipermail/yum/2003-August/001724.html [2] "more thoughts on yum.conf and packages/repositories" - Aug 2, 2003 https://lists.dulug.duke.edu/pipermail/yum/2003-August/001731.html -------------- next part -------------- A non-text attachment was scrubbed... Name: server-scoring.patch Type: text/x-patch Size: 6189 bytes Desc: not available Url : http://lists.dulug.duke.edu/pipermail/yum/attachments/20030828/50fd8c88/server-scoring.bin
