On Wed, Jul 30, 2003 at 12:41:44AM -0400, seth vidal wrote: > > - I want to force a priority sequence for my Yum servers, so that > > packages of a higher prio server do *always* take precedence over > > packages of a lower prio server, regardless the version numbers. > > > I assumed "pkgpolicy=last" would do this, but it seems to work only > > partly: when a new package is installed, it indeed takes the one > > from the higher prio server, regardless how the version compare. > > But if a package is already installed, it doesn't upgrade (in my > > case this means downgrade) to the version of the higher prio server. > > > > I can't really understand this policy, as in this way client > > systems using the same Yum servers end up with different package > > sets (versions), dependent on the time a package was installed. > > This is an unwanted behaviour, IMHO, as systems like Yum should > > ensure a uniform set of client systems (except for what packages > > are installed, but this can be tweaked with special packages). > > downgrading is not as easy as it appears and dealing with downgrades in > operation will take some effort. I think the solution can be made backwards compatible as follows: make a variable allow_downgrade or so (global or per repository), which defaults to "no". If set to "yes" (for all repositories), you'll have a strict preference of repositories. Anyway, for me it is currently a show-stopper for starting to use Yum, as I need to be able to force packages overruling others. > You should look HARD at the system in question about the segfaults. I > haven't gotten ANY segfaults from yum that weren't related to hardware > going funky. Will do some more tests and come back on this. > So it's been on the 'thinking about' burner for a bit so I don't end up > painting myself into a corner with some ridiculous interface to it. Good point. > > - When I rename a server id in /etc/yum.conf, the old cache info > > (with the old server id) never seems to be removed, not even > > with "yum clean all". > > right -b/c at that point yum knows nothing about it. It's the only nice > way to deal with multiple config files - so they don't tread on each > other's cache. OK, but it still would be handy to have something (except "rm") to get rid of old files if you really want that. > I'd like to have a set of external python scripts that handle kernel > updates and kernel modules and all sorts of stuff like that - these > scripts would come in the yum rpm by default but you could easily add > more in a sane way. Right. > As it is - I want yum's default behavior to stay relatively the same. I > like that it handles kernels correctly out of the box, I like that I > don't have to tell people to specify some bizarre incantation to get > kernels to install, let alone update grub.conf correctly. Exactly. > so make your list - and put them in some RFE's in bugzilla and I'll get > through them as I can or as it makes sense. > > if someone wants to make patches against cvs for such things let me know > - I'll be interested to see what can happen in the coming months to free > up a lot of the older crufty code that eats up space in yum. OK, will think about it. Thanks, -- -- Jos Vos <jos@xxxxxx> -- X/OS Experts in Open Systems BV | Phone: +31 20 6938364 -- Amsterdam, The Netherlands | Fax: +31 20 6948204
