Bug 512259

Are you using rhn satellite or are you using a local yum repository?

This is a local yum repository, created with simply "createrepo ."

 The subject of this BZ doesn't match the desired RFE. You have:

pkgA-1 installed
pkgB-1 installed

pkgA-2 available
pkgB-2 available

> Updated package "B" should install and package "A" should not.

...this is not a feature that yum provides, by default, no matter if you use "conflicts A > 1" or "requires A <= 1" ... yum will happily do a "yum update pkgB" or "yum update pkgA" but "yum update pkgA pkgB" will fail because both can't be done at once (and "yum update" with no arguments is basically the later).
 Asking yum to guess if it should install pkgA-2 or pkgB-2 when you've asked for both is against what most people want from it.

 Now you could, say, have a package which used versionlock (or a similar custom plugin) to remove versions you didn't want ... also if you pass --skip-broken (or set the config.) then yum will very likely remove pkgA from a complete update set, of course you should test this ... and it will still look kind of broken.
 And as I said, you can do what you are doing now as long as your customers are happy to not use "yum update" without arguments (and without conflicting arguments).

 Probably the recommended best practise would be to have multiple repositories, and point customers to the one containing the latest versions of what you want them to install.

How is this not a bug?

We're not specifically telling yum to install or upgrade a given package, just running the "yum update" command alone.

This update command is being executed automatically by a cron'd script on each machine on a nightly basis. The customers do not do this on an individual basis, we're talking hundreds if not thousands of machines.

Surely expected behaviour should be for Yum to look at all packages available and react according to basic logic rules to figure out what should be updated from what is in the repository? There's no logical inconsistency here, its very clear and determinable what should occur.

Is having a separate repository for every application times every group of machines really considered "best practice"?

> Surely expected behaviour should be for Yum to look at all packages available
> and react according to basic logic rules to figure out what should be updated
> from what is in the repository?

 "yum update" doesn't mean do all updates that work, but find all available updates and try to apply them. Eg. it's like "yum update" == "yum update *" just as "yum list" == "yum list *".

 Also, as I said before, the situation you had the user could update _either_ pkgA or pkgB without problems ... so any deterministic rules about what to update would have to give up (or guess which one is desired -- creating a giant mess when used over hundreds/thousands of machines).

 Also, as I said before, if you do "yum update pkgB" then it'll do what you want ... you just can't use the "update everything" when you can't actually update everything. But for semi-automated runs on 100+ machines this might not be a big concern.

> Is having a separate repository for every application times every group of
> machines really considered "best practice"?

 How would this be worse than having custom versions of certain packages?

 In general, yeh, if you want subsets of all your machines to update differently, then you'd want to do it via. a specific repository for those machines.

 However when managing 100s-1,000s of machines, the desire is often to keep them in sync. as much as possible ... so having a single "testing" repository for all applications would seem reasonable. At worst you could use this one testing repo. to run specific application updates via. something like:

 yum update --enablerepo=testing blah

Just as a quick addendum, the yum "versionlock" plugin seems the best compromise for us.

We just update the "regional" package with SPEC scripts to created/edit the "/etc/yum/pluginconf.d/versionlock.conf" and set enabled = 1; save it, and create/edit "/etc/yum/pluginconf.d/versionlock.list" with each package we want to stay at a particular version listed in there.

That way the list of "locked" versions can be maintained easily, in one place, without creating multiple repositories, or requiring the "yum update" process be executed manually or with any special instructions. When the customer has had an opportunity to complete their QA process we release another "regional" package which removes the locked listings.

I still think "yum update" should be smart enough to update whatever it can without failing to an error state in the event of any sort of conflict anywhere, but this at least solves the problem for us in the meantime!

Thanks again for the heads up.