Description of problem: We distribute software to our customers in different regions using RPM packages and Yum repositories. We want to restrict certain regions/customers to specific versions of our software, pending a complete QA process. However, when we set the "Requires" field of a given RPM package to be less than, equal to, or less than or equal to, Yum completely ignores these settings, either trying to upgrade software anyway, or even failing with "missing dependency" messages for packages already in fact installed on the system! Version-Release number of selected component (if applicable): yum-3.2.19-18 How reproducible: Every time. Steps to Reproduce: 1. Install a software package "A" with a given version number on a system (example 1.0-1). 2. Install a second package "B" on the same system. 3. Create an updated version of package "A" (example 2.0-1). 4. Create an updated version of package "B" with an entry "Requires: A = 1.0" 5. Release both updated package to the same yum repository 6. Execute a "yum update" command. Actual results: Yum update fails listing a conflict or missing dependency Expected results: Updated package "B" should install and package "A" should not. Additional info: Here is some output from out test system to further illustrate the issue. In this instance package "A" is "eyemagnet-system" and package "B" is "eyemagnet-region-brazil" We do *not* want the "eyemagnet-system" package to update on the Brazil systems (which each already have an "eyemagnet-region-brazil" package installed) On the current system, here are the current versions: [root@site0034 ~]# rpm -qa | grep eyemagnet-system eyemagnet-system-5.0.58-11 [root@site0034 ~]# rpm -qa | grep eyemagnet-region-brazil eyemagnet-region-brazil-1.0.1-5 An update eyemagnet-system package, eyemagnet-system 5.0.59-4 is available in the repository, but we do not want systems with the eyemagnet-region-brazil package to install it. The updated package, eyemagnet-region-brazil-1.0.4-8.noarch.rpm, has the following settings in its SPEC file: Requires: eyemagnet-system = 5.0.58-1 Here is some of the relevant output from the failed attempt to use yum to update this system: [root@site0034 ~]# yum update ... ---> Package eyemagnet-system.noarch 0:5.0.59-4 set to be updated ---> Package eyemagnet-region-brazil.noarch 0:1.0.4-8 set to be updated --> Processing Dependency: eyemagnet-system = 5.0.58-1 for package: eyemagnet-region-brazil --> Finished Dependency Resolution eyemagnet-region-brazil-1.0.4-8.noarch from eyemagnet-staging has depsolving problems --> Missing Dependency: eyemagnet-system = 5.0.58-1 is needed by package eyemagnet-region-brazil-1.0.4-8.noarch (eyemagnet-staging) Error: Missing Dependency: eyemagnet-system = 5.0.58-1 is needed by package eyemagnet-region-brazil-1.0.4-8.noarch (eyemagnet-staging) Again, not only is eyemagnet-system version 5.0.58-1 present in the Yum repository, it is in fact already installed on the system! Incidentally, we have also tried inserting "0:" before the version numbers (ergo "Requires: eyemagnet-system = 0:5.0.58-1" but that seems to have no effect. Nor does using "<=" or "<" (such as "Requires: eyemagnet-system < 5.0.59".
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.