On Thu, 2005-06-23 at 15:14 -0500, Connie Sieh wrote: > Seth, > > On Thu, 23 Jun 2005, seth vidal wrote: > > > > > you can do all sorts of things to pre-empt them by using include/exclude > > > > lists but it's not the same thing as having a 'trump-card repo' > > > > > > But maintaining include/exclude lists is also hard when you are pointing > > > to "arbitrary" repositories. It is not practical to scan the repositories > > > and build include/exclude lists to add the functionality that was removed. > > > > I don't disagree. But repository scoring as a super-epoch to trump > > versions of packages that are higher seem like the wrong solution to me. > > > > -sv > > Here is the situation. Maybe you can help find a better solution than > repository scoring. > > We have Scientific Linux Fermi. It has mostly the same rpms as Scientific > Linux(RHEL rebuild). We have a yum.conf that points to the rpms for both > Scientific Linux Fermi and Scientific Linux. Scientific Linux Fermi has a > older version of openssh that we backport security patches to. In the > older yum we just gave a higher "priority" to Scientific Linux Fermi and > our openssh was never updated to the newer version in Scientific > Linux. Now we have to add openssh to the excludes of Scientific Linux. > Not too bad to do when we have only 1 or 2 rpms in this situation but when > there are alot of them then this can be very error prone(manual adding to > config file). > > So do you have any suggestions other than excludes on how to do this? > well the easiest way to escape the error prone would be to take advantage of the include= options in yum 2.2.X and higher. include=http://server/path/to/some/file and that url is: exclude=openssh* you can add it to the same file multiple times and effect the same change but make the change in only one place for every machine. However, your point about needing another way to do it on a larger scale is not w/o merit. I'm just at a loss for how to do it with out resorting to scores. The problem I have with scores is how prone to error they become, especially when we start trying to debug the depsolving and update-calculation when confronted with data that is clearly not in the package information itself. The longer answer to this question is - if you have a specific need like this is that in yum 2.4 the plugins will allow you to do whatever you want to determine how something gets excluded. I know Panu has already written a pinning plugin to pin certain items at certain versions, he does that through a series of exclusions that expose themselves as 'this version and no more' in the plugin he wrote. -sv
