seth vidal wrote: >>Ah. configparser issue. Ok, I can live with that, and will dream no >>more. More important to me, though, is for the last repository in the >>list to trump all earlier repositories (alphabetical is OK...I've been >>doing it this long and it hasn't hurt me none). It kind of botches the >>way I'm using yum for it to work this way when installing new packages, >>but when replacing and existing package it keeps the 'newer' one based >>on version or epoch. > > > I don't understand what you mean here. > > Can you explain your issue a bit more? > > Did you want yum to "update" the packages to older versions? like > --oldpackage or something? Yes. Exactly. I maintain a bunch of Squid packages, among other things, spread out across countless yum repositories (4 versions of Red Hat, different versions of Squid, 2.4, 2.5 and 3.0, plus a private repository for every system we ship or install). None of my packages have an epoch. So according to RPM, my Squid packages are /always/ older than the Red Hat packages. Obviously, I want no truck with Red Hat squid packages when I've got so many of my own to worry over. ;-) I always kind of thought that was the way yum behaved, because Squid didn't get installed until yum did it in the final stage of our automated installation, so I didn't see yums update behavior under these circumstances. Then I started doing installations on existing web caching servers for clients and realized that yum wouldn't replace an existing 'epoch-enabled' Squid package no matter what I did, or how nicely I asked. So I have to remove the offending package, and then install fresh (before this morning, I thought I had to install the correct package and its deps manually using the oldpackage option and add Squid to the exclude list, but I figured out that a fresh install always does the right thing and won't get written over later). Squid isn't the only package that has this problem, but it's the most common source of my troubles. The problem is compounded by Squid daily snapshot versioning, which also has bizarre version comparison behavior with RPM. But I'll have to take that up with my own packages--yum can't fix that. ;-) >>I suppose I could rethink my package versioning and the way I'm using >>yum, to include epochs to force this kind of behavior at the package >>level. I fear that way will lead to madness...I have a multi-tiered >>method of deploying software and bundles of software, and it makes my >>head hurt to think of some way to epoch this without breaking previous >>deployments. And epochs make me itchy. I don't like packages getting >>uppity with me and acting all newer than one that I can clearly see has >>a more recent version number. ;-) > > > Do not use epochs lightly. Once you start down that path it is difficult > and sometimes impossible to return. Entirely impossible to return. I've been trying for ages to get out from under Red Hat's epoch'ed Squid packages, and it just gets more difficult with time... ;-) Don't worry too much over the issue...I just had a frustrating bout of talking someone new to yum through installing packages from a custom repository--all of which were epoched in the Red Hat versions and already installed. It took more than half an hour for me to realize yum didn't behave at all like I thought, and quite a bit longer to think through how to work around it (these packages had a lot of deps, making the remove/reinstall fix less than fun). Now that I understand it, I can work around it relatively easily--and I very likely will still give a go to adding a 'really-last' option that will 'downgrade' packages as needed to prefer a later repository over an earlier repository. Thanks! -- Joe Cooper <joe@xxxxxxxxxxxxx> Web caching appliances and support. http://www.swelltech.com
