Bug 75344
| Summary: | RFE: /var/log/rpmpkgs should show changes to RPM installs/updates/deletes | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Linux | Reporter: | Tom Wood <woodt> |
| Component: | rpm | Assignee: | Jeff Johnson <jbj> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 8.0 | CC: | tammy.c.fox |
| Target Milestone: | --- | Keywords: | FutureFeature |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2002-10-10 20:51:14 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Tom Wood
2002-10-07 14:44:53 UTC
This is a nice RFE. However, redhat-logviewer just read the /var/log/rpmpkgs file generated by /etc/cron.daily/rpm from the rpm package. Changing to correct component. Why did someone bother with creating this daily cron job, when "rpm -qa" on the fly (1) doesn't take that long to run and (2) is at least as correct if not more so than "rpm -qa". If you've had changes that day, you can't rely upon this tool giving you the current status of your RPMs. I would submit that redhat-config-logviewer needs to run "rpm -qa" and do away with a static, potentially out-of-date file reference. rpm -qa assumes that you have a functional database, the cron job is for disaster recovery when you don't have a database. Please explain how the cron job is for disaster recovery. It doesn't seem to copy/backup the real rpm database. Therefore, how can it be used in the case of the rpm database being corrupted to the point of uselessness. I for one would like to see more robustness vis a vis the rpm database. On a RH system, it's one of the most critical and most fragile parts of the distro. The list of package names installed can be used as a manifest to reconstruct the database using --justdb. IMHO, the rpmdb is neither critical or fragile, but rather a pile of redundant and reconstructable data given the installed package manifest. Well, will the limits of my ignorance ever be fully charted? ;-) Thanks for enlightening me. The major issue for running an install (and erase, harder) log is where to put the data, and how to maintain integrity and accuracy when, say, there are multiple clients with different versions of rpm all doing installs. There's no easy answer here, so an implementation can't be attempted. Running rpm -qa cron more frequently, and saving diffs periodically is probably the best answer ATM. Please clarify what you mean when you say "there are multiple clients with different versions of rpm all doing installs". I don't see how this applies to the normal case where you have a single version of rpm on a machine at a time. Is it so hard to track configuration file changes in a semi-sane manner? In the last 4 versions or so, we've moved from usually (but not universally) replacing config files and saving the old ones as *.rpmorig or some such, to not replacing the config files and calling these *.rpmnew. |