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:
** Message: sqlite cache needs updating, reading in metadata
$ rpm -q yum-metadata-parser yum yum-cron
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
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
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 latest yum-cron for EL5 now comes from CentOS, so I'm moving the issue