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): rpm-4.4.2.2-3 How reproducible: Always Steps to Reproduce: 1. read /etc/cron.daily/rpm 2. read /var/log/rpmpkgs 3. run "rpm -qa" Actual results: Expected results: Additional info: 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 is silly. 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 period.
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 http://www.redhat.com/archives/rpm-list/2004-August/msg00183.html. 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 brief description.