Red Hat Bugzilla – Bug 430374
redundant rpmpkgs file
Last modified: 2008-01-28 03:35:28 EST
Description of problem:
The rpm distribution contains an /etc/cron.daily/rpm file which generates a
pointless /var/log/rpmpkgs which is not used by any other application except
/usr/sbin/sysreport. The exact same information can be generated
(more-accurately) by "rpm -qa".
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. read /etc/cron.daily/rpm
2. read /var/log/rpmpkgs
3. run "rpm -qa"
Why? If sysreport is supposed to collect information "... be used for
diagnostic purposes and debugging ..." then how can a report that contains
information about rpms that is only collected on a daily basis be of any use?
It wont contain any information about recently installed rpm's. So any "...
support technicians and developers ..." are going to be wasting their valuable
time depending on sysreport.
So Joe Bloggs installs a new rpm; system becomes unstable; contacts tech; tech
looks at sysreport; tech doesn't show recently installed rpm; tech wastes whole
day looking at all of the wrong things; tech's reputation tarnished forever.
The rpmpkgs file provides a list of what was installed
for rpmdb disaster recovery, nothing more.
Sure you can do "rpm -qa" and get more accurate info.
Oh wait, the rpmdb is damaged ...
If it is damaged then restoration from a backup would be better.
What good would a list be anyhow? It cannot be turned into a rpmdb can it?
A reversible dump of rpmdb would be one thing, but an out-of-date list
But, more importantly, if rpmdb is corrupt and sysreport doesn't even try a "rpm
-qa", what is the point of sysreport? A corrupt database and sysreport doesn't
detect it?! Sysreport might as well create a snapshot of everything on an
annual basis and gratifyingly report everything as being 100% in the intervening
The rpm cronjob just periodically collects data about system state. That data
may or may not be useful in case of a disaster, much like anything else in
/var/log. Besides just inspecting what was on the system you can actually turn
an rpmpkgs file into a healthy rpmdb by using it as a package manifest, see
If sysreport isn't collecting live data even when it could then file a bug
against sysreport, that ain't rpm's fault.
But rpm contains a script which specifically generates rpmpkgs for the sole use
by sysreport. Therefore rpm is a friend of sysreport and therefore they can
share this bug report.
It might be a good idea to move the cron.daily/rpm script into sysreport, since
it is purely sysreport functionality.
The script has NOTHING to do with sysreport. If sysreport happens to use the
files created by the script it doesn't mean that's it's business.
Erm, the above should've read:
If sysreport happens to use the files created by the rpm cron script, that's
solely sysreports business, not rpms.
So what is the point of the rpmpkgs file?
See comment #1.
Couldn't "... rpmdb disaster recovery ..." be something as absurdly simple as
"cp /var/lib/rpm/__db* somewhere/"?
Check database, then if ok copy to backup.
But it seems that nobody, especially redhat, have faith in their rpm database.
In which case, why not just make the database an ascii file in the first place?
It isn't as though 50Kbyte is a large file which merits the use of a database.
Uh... The __db* files are not the database but BDB "environment", they're 100%
useless for reconstructing a broken db. Here's a clue why rpmpkgs is provided
for disaster recovery aid instead of backing up the full db daily:
$ ls -l /var/lib/rpm/Packages /var/log/rpmpkgs
-rw-r--r-- 1 root root 44273664 2008-01-28 09:52 /var/lib/rpm/Packages
-rw-r--r-- 1 root root 44355 2008-01-22 04:17 /var/log/rpmpkgs
So a file 44355 bytes in size contains sufficient information to reconstruct the
44MB database? Doesn't that imply that the database is unnecessary and could be
replaced by a simple directory of spec files (and companion files) or similar?
Of course is not sufficient alone. The rpmpkgs file contains information
sufficient to *aid* in reconstructing the db, read the link in comment #3 for a