dpkg.log reworked

[Ben Collins <bmc@visi.net>]

Ok, here's how I see it working (the almighty master plan ;)

#!/bin/sh
# postinst (preinst, etc...) for package foo-dev

# package related stuff

logger -p local6.info -t "pkg:foo-dev" << EOF
Package foo-dev may need some configuring before you can use it too
full potential
EOF

if [ some test ]
then
    echo "There was a problem with blah blah, you need to edit it manually"
    logger -p local6.alert -t "pkg:foo-dev" << EOF
There was a problem with blah blah, you need to edit it manually
EOF
fi

# end postinst

NOTE: local6 is for example purposes, it could be any localN priority
we set. Also the levels used could be defined in the policy as to when
it is appropriate to use which one (the same as we do for bug severity)
and is completely up to the maintainer as to whether or not he/she
needs to use it. The preceding "pre:" in the log tag is only there to
seperate it from other log entries. For example if the real syslogd
logs messages we don't want it confused with messages sent from a
syslogd postinst script.

Also, dpkg could follow suit by adding syslog calls to it's output
messages based on the same criteria. For example:

"dpkg: updating foo-dev, old version 1.0, new version 1.1"
or
"dpkg: failed to install foo-dev, depends on foo which is not installed"

-----

This has several advantages:

1) The maintainer chooses the log level (ie. how important the messages
are), this allows the admin to setup what he wants logged and where it
get's logged to by configuring syslog. The default syslog setup could
have local6.info output to /var/log/dpkg.log. It also keeps dpkg from
having to handle this extra load.

2) We don't have to reinvent the wheel by making extra programs and
utilities to handle this. Admins are already familiar with syslog and
it does everything we need it to do.

3) Easy to implement. Define the policy regarding the log priority to
use for package related messages (localN). Define the log levels to
use for what type of messages (alert, warn, info, etc..). Then have
the syslog package add the proper default entry into /etc/syslog.conf.
After that packages can start useing the feature. Package programs such
as dpkg and apt could then follow by adding calls to syslog if so desired.

One thing I also see in the future for this is if dpkg and friends
implement a non-interactive process for install, then when the packages
check for this type of install it could make decisions on where and
what to output messages to. For example if a package is under
non-interactive install it could then choose to output messages to the
log to let the admin know that he/she needs to run the pkgconf program
in order to complete the setup, otherwise the package would simply
execute the pkgconf program itself (ie. sendmail, cvs...)

--
-----    -- - -------- --------- ----  -------  -----  - - ---   --------
Ben Collins <b.m.collins@larc.nasa.gov>                  Debian GNU/Linux
UnixGroup Admin - Jordan Systems Inc.                 bcollins@debian.org
------ -- ----- - - -------   ------- -- The Choice of the GNU Generation