Description of problem: There is a very general problem in yum rhnplugin and rhn_check. It breaks down to the following individual problems: Yum rhnplugin issues - rhnplugin metadata don't expire for a very long time - rhnplugin does not respect the yum.conf setting metadata_expire - rhnplugin does not (seem to) have a way of simply testing if server repodata are newer then what is currently worked with rhn_check issues - rhn_check will only call yum with very unspecific install options - therefore it will return success even if it installed something completely different then what the user requested - Most times this is due to old client side repodata still containing older versions How reproducible: Apply new package to channel and try to install it shortly after that. There is a level of randomness, but chances are great that it will not see the new packages. Steps to Reproduce: 1. Apply errata to channel (New repodata will be generated) 2. Schedule installation of this package on a system via rhn/satellite 3. rhn_check will run and (most likely) still use the old metadata. Effect "yum install packagename" will not fail, but it will not install the version the user expected. Actual results: Some old package is installed. Expected results: Exactly the last version in the channel. I see two options to solve that. rhnplugin should check the repodata timestamp before it does anything and download changes if necessary. (prefered option) Something like a HEAD request on those details. That should be cheap enough to have to happen every time. This option could be a parameter for yum which is not used by default but enabled when used by rhn_check. rhn_check will do yum makecache before issuing yum jobs to be sure yum is up to date. (stupid, but will work) Additional info: This is connected to another generic problem with rhn_check. It will translate the job "install packagename-version.arch into "yum install packagename.arch" which will always install the last version (known by the client) and not do exactly what was requested. I will create a BZ for that issue later...
I think I just disproved my theory that rhn_check will ignore the version of the package scheduled for installation. With yum-rhn-plugin-0.5.3-30.el5 rhn-check-0.4.20-33.el5_5.2 I have [['iptstate', '1.4', '2.el5', '', 'x86_64']] { 'flags': [], 'packages': [(['iptstate', '1.4', '2.el5', '', 'x86_64'], 'i')], 'probFilterFlags': [], 'vsflags': []} in transaction_data in /usr/share/rhn/actions/packages.py -> runTransaction via packages.update in /usr/share/rhn/actions/errata.py Not sure if this was recently fixed. I was rather sure about that not being the case. I thought it would only call the equivalent of yum update packagename. Anyway, this is not the main problem here of course. I thought this was the reason install requests for package versions that yum does not know result in just the last known version being installed and rhn_check reportung success to rhn. But as I said, this is only half of the problem.
Created attachment 470929 [details] a temporary patch which allows rhnplugin to read metadata_expire value from yum.conf