Bug 689771

Description of problem:
While the yum-rhn-plugin's cache is not expired, rhn_check will use the data from yum-rhn-plugin to attempt to install an update and report as a success the non-installation of the update because it can't see it in the cache.

Version-Release number of selected component (if applicable):
rhn-check-0.4.20-46

How reproducible:
all the time, with satellite and with rhn.

Steps to Reproduce:
1 on a client that syncs normally to a satellite (reproducing against RHN is possible but takes a lot more time)
2. disable osad and rhnsd on the clients.
3. perform a "yum clean all ; yum check-update" on the client to make sure the cache is freshly generated
4. push a new version of a package to the satellite, create an errata out of it optionally.
5. wait until the repodata are updated ; this should happen before the yum-rhn-plugin cache expires
6. plan from the satellite/rhn the installation of the new package
7. execute rhn_check on the client
  
Actual results:
We will see that the server has reported the installation of the new version as successful, however the new version was not installed because it was not listed in the yum-rhn-plugin cache at the time rhn_check used it.

Expected results:
rhn_check fetches the latest version of the repodata if the package cannot be found in the non-expired cache instead of stopping there and reporting the action as a success.

Additional info:
This issue also makes it impossible to distribute erratas within less than the time it takes for the yum-rhn-cache to expire. some old bugs of yum may even cause it to never ever install any updates until the cache is manually cleaned, which can become a problem in parks with a large number of machines that can be impacted by the issue.
another side of the issue affects the auto-application of erratas : as rhn/satellite automatically plans the actions, they all are reported as successful but the updates may not have been installed. these actions may not be replanned at all for rhn and require a manual intervention every time it happens.
Because of this issue, a customer may plan the installation of erratas and his systems might still be vulnerable to what they fix.