On CentOS 5, if yum-metadata-parser is installed, settings DOWNLOAD_ONLY=yes, I get a cron email apparently every time a repository has changed even if there were no updates available for the system: /etc/cron.daily/yum.cron: ** Message: sqlite cache needs updating, reading in metadata $ rpm -q yum-metadata-parser yum yum-cron yum-metadata-parser-1.0-8.fc6 yum-3.0.5-1.el5.centos.2 yum-cron-0.6-1.el5 rpm -e yum-metadata-parser appears to fix it, but it'd be better if yum-cron could convince the sqlite cache to shut up.
yum-cron is already invoking yum with "-e 0 -d 0", which is the minimum possible verbosity level. The "Message:" output yum is giving strikes me as an informational level of message that yum shouldn't be sending to stdout at verbosity level 0. yum-cron cannot squelch stdout entirely, since we're asking it to output a list of needed updates. It also cannot ignore stderr, since we'd like to know when something fundamental is broken. So, it looks like this bug is really in yum-metadata-parser - it has an informational message which is not obeying the overall yum verbosity rules. Reassigning the bug to yum, as yum-metadata-parser isn't a bugzilla component of its own.
Alec, yum in el5 is not maintained in EPEL, it is part of RHEL/CentOS proper. Ville, if you agree with Alec's assessment, I think re-opening this as a CentOS bug would be appropriate.
Well, the EPEL yum-cron upgrades the CentOS one so chances are that we'll be seeing a ping pong effect if this is reported there.
It's not a yum-cron issue, it's a yum one, likely upstream anyway regardless of the distribution. Part of yum simply has a debugging statement that's not listening to the verbosity flags, yum-cron makes us of those flags so notices the bug.
The latest yum-cron for EL5 now comes from CentOS, so I'm moving the issue there. http://bugs.centos.org/view.php?id=2514