Bug 20177 - rpm to keep log of it's doings
rpm to keep log of it's doings
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
7.1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
David Lawrence
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-11-02 02:10 EST by Pekka Savola
Modified: 2007-04-18 12:29 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-12-09 04:53:53 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 Pekka Savola 2000-11-02 02:10:19 EST
This is, IMO, a high priority enhancement request.

RPM should keep log of all changes in RPM database.  This is because
those funky warnings about .rpm{save,orig,new} etc. usually scroll off 
way too fast when upgrading a lot of packages, or are generally ignored/forgotten
when something happens.  Also, this serves as a very good change history and is
good for debugging problems with packages.

FWIW, AutoRPM records the following:

---
Thu Oct 12 23:25:59 EEST 2000 - tmpwatch-2.2-1 -> tmpwatch-2.6.2-1
---

The log, logged to e.g. /var/log/rpm.log should consist of at least the following:
 - Upgrades and installations
 - Removals of packages, including those caused by Obsoletion
 - If anything was output, that would have to be saved in the file in a meaningful form
 - with --nodeps, --force, --oldpackage or the like were used, record it was used and 
what were the problems without the command.

Some of these can be done with external programs too, but IMO, this really should be 
an integral feature of RPM.

I'm not sure if Debian packaging system does some of this, it might be worth a look
for ideas.
Comment 1 Daniel Roesen 2000-11-07 07:17:44 EST
Request seconded.
Comment 2 prazak 2000-11-10 10:57:19 EST
if you wnat to have just the output of a command, run the 'script file' before
the particular command and you will have a log in the 'file'.
Comment 3 Michael S. Fischer 2001-01-30 19:37:42 EST
I will also chime in my support for this enhancement.  I'd like to see it ASAP.
Comment 4 Aleksey Nogin 2001-08-16 16:47:47 EDT
I agree, this would be extremely useful.
Comment 5 Dag Wieers 2001-12-09 04:53:49 EST
I wanted something like this for ages and was thinking of putting it in Bugzilla
just now. If you're administering lots of computers with a small team, one thing
you need is a logbook of all changes. We've got a policy of only installing
RPM-packages but there was no real way to track changes to the RPM database.

(We use check-packages, but the output s*cks and the fact that it mails the
output and you loose actions if things are reverted makes it sometimes useless)

Another feature I'd like to see implemented (and will add here if not already
so) is:
  + A way to lock a package so rpm won't upgrade it automatically (even won't
force it) unless it is explicitely unlocked. (Maybe locking is not possible from
within the RPM-package itself to avoid 'sticking' packages that you cannot
uninstall or something). See it as a flag so you can tell other administrators
that this package has some 'importance' attached to it. Like you could lock the
kernel-package on a certain system to draw the attention that it is a custom
package, or you can lock production-application to avoid they get updated by you
r new colleague administrator.
Comment 6 Jeff Johnson 2001-12-09 11:57:35 EST
While I understand the need, I believe this is a system administration,
not an rpm, problem.

For starters, periodically saving the output of
	rpm -qa | sort > per-machine-manifest
gets you most of what you want, i.e. package x changed
at time period y on machine z. If you want/desire more specific info,
you can use --queryformat to extract other information from the installed
package database. 'Tain't hard, I've used a cron driven cvs checkin
to watch the rot in Red Hat build tree's in the past, worked quite
well IMHO. Looking at the periodic reports tells you what was
removed when, try using "diff".

Now for logging in rpm. If I were to implement logging, I believe that I
would almost instantly get dozens of request for this or that format, I
can't possibly devise a format that keeps even a plurality of people
happy. Furthermore, since rpm has --root  i.e. must be able to run
in empty chroot's etc, logging must be able to be disabled/configured/etc,
I don't believe that I can ever devise a sufficiently general and well
understood reporting mechanism to be useful.

In fact, using popt aliases, there's literally no reason why a disciplined
system administrator can't figger a new rpm command line option to re-execute
rpm within a script to log whatever information (i.e. login user/tty, date,
command
line options that was used, etc.) is desired for "logging". while
installing/upgrading
packages without changing rpm.

OK, time to put on the flak suit :-). I'm gonna close this bug "WONTFIX".

Comment 7 Dag Wieers 2001-12-09 19:04:09 EST
I think you're wrong ;-) No offense though ;-)

First of all, I cannot log all changes to the RPM database as a lot of programs
use libraries (either through perl, python or c) and therefor my rpm-wrapper
(which I have written) is of limited use.

Secondly, your first argument (that it is a system administration problem) makes
no sense as rpm was there to facilitate the system administrators job. So it
fits right into rpm's purpose.

Finally, your second argument (that the log-format wouldn't make everyone happy)
is not a real argument. This argument could be used by virtually everybody who
has to implement logging. It makes no sense that you won't do it because you
cannot make everybody happy with the format.

Then you suggest to use something that diff's, which I'm using on all systems.
It's called check-packages and is sending me a bunch of mails foor every machine
every day and it can only capture changes from one day to another. There's no
way I can see whether it had been uninstalled first and then reinstalled by a
newer. (Which makes a huge difference than upgrading). Things like that I cannot
possibly know (certainly not when applications like autodld or autorpm use
libraries).

The problem with the chroot and stuff can easily be fixed (log on chroot if log
exists there). You could even apply that logic always (so I can touch the file
to make it start logging).

So, is it possible to discuss this with other RPM-developers or sysadmins inside
Red Hat ?

It would be greatly appreciated, even if the verdict is negative. Thanks !

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