yum package version availability does not work with --enablerepo

Matthew Kent added a comment - 21/Jun/11 5:37 PM The yum provider in 0.10.2 has been rewritten and allows for this attribute: flush_cache [ :before, :after ] that you could use to dump the cache before attempting the install with the enabled repo. I believe this should do the trick but will help test this once 0.10.2 is released.

ZombieDev added a comment - 10/Aug/12 9:26 PM This is still a problem in Chef 10.12.0. Also, flush_cache doesn't fix the problem as it does not affect what candidate version the yum provider finds. Here I try to install mercurial 2.2.2 on centos 6 from the rpmforge-extras repo (which is installed by the repoforge-release rpm but is disabled by default). include_recipe 'yum::repoforge' yum_package "mercurial" do action :install flush_cache [ :before ] options '--enablerepo=rpmforge-extras' end this is the log: [2012-08-10T17:10:33-04:00] DEBUG: Processing yum_package[mercurial] on centos6.example.com [2012-08-10T17:10:33-04:00] INFO: Processing yum_package[mercurial] action install (mercurial::default line 23) [2012-08-10T17:10:39-04:00] DEBUG: yum_package[mercurial] checking yum info for mercurial [2012-08-10T17:10:39-04:00] DEBUG: yum_package[mercurial] installed version: (none) candidate version: 1.4-3.el6 [2012-08-10T17:10:39-04:00] INFO: yum_package[mercurial] installing mercurial-1.4-3.el6 from base repository [2012-08-10T17:10:39-04:00] DEBUG: Executing yum -d0 -e0 -y --enablerepo=rpmforge-extras install mercurial-1.4-3.el6 [2012-08-10T17:10:47-04:00] DEBUG: ---- Begin output of yum -d0 -e0 -y --enablerepo=rpmforge-extras install mercurial-1.4-3.el6 ---- [2012-08-10T17:10:47-04:00] DEBUG: STDOUT: [2012-08-10T17:10:47-04:00] DEBUG: STDERR: [2012-08-10T17:10:47-04:00] DEBUG: ---- End output of yum -d0 -e0 -y --enablerepo=rpmforge-extras install mercurial-1.4-3.el6 ---- [2012-08-10T17:10:47-04:00] DEBUG: Ran yum -d0 -e0 -y --enablerepo=rpmforge-extras install mercurial-1.4-3.el6 returned 0 [2012-08-10T17:10:47-04:00] INFO: yum_package[mercurial] installed version 1.4-3.el6 The flush_cache makes no difference. It still finds 1.4-3.el6 as the version to install. I think this is because the --enablerepo switch needs to be passed to whatever is finding the candidate version. For example, when I pass it into this command I can see the 2.2.2-1.el6.rfx version from rpmforge-extras [admin@centos6 ~]$ sudo yum list --enablerepo=rpmforge-extras mercurial Loaded plugins: fastestmirror, security Loading mirror speeds from cached hostfile * base: mirror.team-cymru.org * epel: mirrors.servercentral.net * extras: mirror.cisp.com * rpmforge: mirror.cpsc.ucalgary.ca * rpmforge-extras: mirror.cpsc.ucalgary.ca * updates: mirrors.cmich.edu Installed Packages mercurial.x86_64 1.4-3.el6 @base Available Packages mercurial.x86_64 2.2.2-1.el6.rfx rpmforge-extras

Matthew Kent added a comment - 10/Aug/12 9:35 PM Ah good point, yum-dump.py probably needs to know about the enabled repo. Hoping to be able to look at this soon.

Matthew Kent added a comment - 28/Oct/12 7:59 AM Took a run at this in: https://github.com/mdkent/chef/tree/CHEF-2427 no user visible changes and only fixes the existing broken behaviour. From my commit log: Teach the yum provider how to handle --(enable|disable)repo passed as options. We collect these options while preserving their order, dump the cache, then pass them along to yum-dump.py during the refresh. yum-dump can now parse these options and enable/disable repos in exactly the same manner yum itself does, thus preserving our cache sanity. The next yum package resource that loads and doesn't have the same options set will blow away the cache. Under the current caching implementation passing these options will add client run time as the cache is rebuilt to account for the differences in package availability. As such I strongly suggest globally enabling/disabling the repo whenever possible.

Bryan McLellan [Opscode] added a comment - 05/Nov/12 7:26 PM It's unfortunate that we're doing magic when --enable-repo happens to be in the options attribute because that's probably non-obvious to users, but admittedly we're behind on a better solution ( CHEF-2698 was the start). From the commit: Under the current caching implementation passing these options will add client run time as the cache is rebuilt to account for the differences in package availability. As such I strongly suggest globally enabling/disabling the repo whenever possible. We should make a similar warning on the resources page about this and note that there is some magic afoot. Anyways, thanks again Matthew.

Bryan McLellan [Opscode] added a comment - 14/Dec/12 4:33 PM cherry-picked to 10-stable