Bug 430374 - redundant rpmpkgs file
redundant rpmpkgs file
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
8
All Linux
low Severity medium
: ---
: ---
Assigned To: Panu Matilainen
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-26 20:48 EST by JW
Modified: 2008-01-28 03:35 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-28 01:13:59 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description JW 2008-01-26 20:48:37 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):
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.
Comment 1 Jeff Johnson 2008-01-27 15:04:37 EST
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 ...
Comment 2 JW 2008-01-27 18:37:11 EST
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.
Comment 3 Panu Matilainen 2008-01-28 01:13:59 EST
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.
Comment 4 JW 2008-01-28 02:07:02 EST
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.
Comment 5 Panu Matilainen 2008-01-28 02:26:54 EST
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.
Comment 6 Panu Matilainen 2008-01-28 02:28:51 EST
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.

Comment 7 JW 2008-01-28 02:32:25 EST
So what is the point of the rpmpkgs file?
Comment 8 Panu Matilainen 2008-01-28 02:34:31 EST
See comment #1.
Comment 9 JW 2008-01-28 02:50:11 EST
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.

Comment 10 Panu Matilainen 2008-01-28 03:06:36 EST
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
Comment 11 JW 2008-01-28 03:14:44 EST
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?
Comment 12 Panu Matilainen 2008-01-28 03:35:28 EST
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.

Note You need to log in before you can comment on or make changes to this bug.