Hi Troy,

On Tue, 1 Apr 2008, Troy Dawson wrote:

> Hi,
> The discussion has come up several times about what to do about updates like 
> cups for SL 4.  I've thought about Stephan's scripts,

hideous ;-)

> and putting in an epoch, or just redoing them all with a new name.  But 
> in the end, I think the solution that will cause the least amount of 
> pain for people will be a yum plugin.
>
> I/We can write a plugin for yum, and we'd distribute it to SL 4.0-4.5.
> The plugin would have a list of rpm's, and if it saw them, it would somehow 
> demote that rpm, so that the rpm that is really newer would be seen and 
> installed.

Right. If you can just make yum completely disregard the "known old" ones 
(with evrs before the crossover to dist tags), whether installed or not, 
*and* make it *down*grade the installed rpms to what's left, this should 
work. I'm just not sure this can be done in a plugin, and I'm afraid it 
can't without changing the actual sorting algorithm in the rpm lib. But I 
admit I have little clue of yum's inner workings.

> So if we take cups for example.
> If yum is going along, and it sees that you have cups-1.1.22-0.rc1.9.20.2.2 
> installed.  It will know that it should demote it somehow, and then when it 
> see's cups-1.1.22-0.rc1.9.20.2.el4_6.6 it will think that it is newer and 
> install it.
>
> The reason I'm thinking a yum plugin is the right way to go is because it can 
> be put in, and taken out.  I think once everyone get's to SL 4.6, I *hope* 
> that we have all the rpm's fixed up correctly and this plugin won't be needed 
> anymore.

FWIW: Since I last wrote about this, we updated all our SL systems to 
4.6/5.1 and I whipped up a few scripts to determine the "right" evr for a 
certain package, where "right" means "highest if you ask rpmvercmp() and 
compare the build times, and if those criteria disagree (one saying 
'higher' and the other 'equal' is not), that's an error". There are no 
such errors in 4.6 or 5.1. And another script to "rpm -U --force" those 
once after the update. Leaving those installed packages alone that 
weren't built on an fnal.gov host. I'm not claiming that's the right 
solution, and doing it with a plugin would be *much* better if it's 
possible, but at least yum updates work again on our systems. Part of 
this may be reusable to provide the input list for the plugin.

Cheers,
 	Stephan


-- 
Stephan Wiesand
   DESY - DV -
   Platanenallee 6
   15738 Zeuthen, Germany