Maybe this is a good time to present this idea I've been kicking around, but never really got anywhere with, for as long as I've been working on debconf. My idea is to add an abstraction layer for package install-related logging in debian.
It seems that many maintainers like to do some or all of the following
in their maintainer scripts:
- Display various fairly unimportant warnings, which are often not
useful until after the package is installed and you're using it.
- Display error messages, some fatal, and some not.
- Show progress displays (in contravention of policy of course).
- Various other indications of important and not so important things
that the maintainer script is doing.
- Remind users to read the README.Debian file.
Almost all of this is done with echo, and almost all of this is
completly ignored by our users, believe it or not. I suppose that those
users who see it would prefer to be able to go back and look at it
later, when they're actually using the package they installed earlier.
Some of them would certianly like for it to be localised. Many users
would like not to see this stuff at all at install time, unless it's a
real immediate error.
So the basic idea is that instead of using echo for these messages,
we provide some interface for them. Call it dpkg-log. I have not gotten
as far as to what the interface of dpkg-log would be, or how users would
configure how it displays, filters, and/or logs messages. Nor have I
given much thought to what kind of data should be included in the log,
though it would probably include the date, package name, log message,
log type, and message importance. Nor have I thought about l10n at all.
This could be bolted on the side of debconf. The abuse of debconf by
maintainers who feel the need to do the kinds of things listed above
certianly points at the need for this mechanism. And at least debconf
has a kind of l10n framework, and some ideas about question priority.
But this logging and message display is really conceptually different
than debconf. Debconf is just there to ask questions. It would likely be
better to design it as a separate program.
Here's one way a dpkg-log program might be used, just to give the feel
for the idea:
#!/bin/sh
if [ "$1" = configure ] && grep -q evil /etc/myconfig; then
dpkg-log --priority=critical \
--warning=$"/etc/myconfig has evil in it! See README.Debian!"
elsif [ "$phase_of_moon" = full ]; then
dpkg-log --priority=critical \
--error=$"This package only upgrades during new moons."
exit 1
fi
The user would see either this:
# dpkg -i mypkg.deb
dpkg: Installing mypkg (1.2.3) ...
dpkg: Not replacing modified conffile /etc/myconfig with /etc/myconfig.dpkg-new
mypkg: /etc/myconfig has evil in it! See README.Debian!
Or if they prefer, this:
# dpkg --log=warning -i mypkg.deb
dpkg: Installing mypkg (1.2.3) ...
dpkg: Not replacing modified conffile /etc/myconfig with /etc/myconfig.dpkg-new
mypkg: 1 warning logged to /var/log/dpkg.log
# cat /var/log/dpkg.log
Date: Thu Jul 3 17:10:33 EDT 2003
From: mypkg
Package: mypkg
Version: 1.2.3
Operation: upgrade
Priority: critical
Type: warning
Message: /etc/myconfig has evil in it! See README.Debian!
Notice that I assume that dpkg-log would be somewhat integrated with
dpkg, such that dpkg would pass it somehow information like the package
being installed, and the version being upgraded to. That's not completly
necessary, as the maintainer script already has most of that information
available for passing to the program, but it would be nice.
One other thing this could be used for, if we find a good enough log
format or write tools to process it, is for logging by dpkg of what it's
doing too (there's a wishlist item that dpkg get logging support that
explains some of the benefits). So /var/log/dpkg.log might really look
more like this:
Date: Thu Jul 3 17:10:33 EDT 2003
From: dpkg
Operation: upgrade
Package: mypkg
Version: 1.2.3
Old-Version: 1.2.2
Priority: low
Type: status
Message: Installing mypkg (1.2.3)
Date: Thu Jul 3 17:10:33 EDT 2003
From: dpkg
Operation: upgrade
Package: mypkg
Version: 1.2.3
Old-Version: 1.2.2
Priority: medium
Type: status
Message: Not replacing modified conffile /etc/myconfig with
/etc/myconfig.dpkg-new
Date: Thu Jul 3 17:10:34 EDT 2003
From: mypkg
Operation: upgrade
Package: mypkg
Version: 1.2.3
Priority: critical
Type: warning
Message: /etc/myconfig has evil in it! See README.Debian!
Date: Thu Jul 3 17:10:33 EDT 2003
From: dpkg
Package: mypkg
Version: 1.2.3
Operation: upgrade
Priority: info
Type: status
Message: Successfully upgraded mypkg (1.2.3)
That's as far as I've ever gotten on how this thing could work. I see
the need, it's a separate need than those that led to debconf, and are
leading to the NEWS.Debian files. The need to communicate with the user
as your program does something is rather engrained in us. Until that
need is met with something designed just for it, we'll continue to see
other mechanisms abused, even if that leads to them being changed in
ways that make them less useful for their intended aims.
--
see shy jo
pgplFDRrUN6K4.pgp
Description: PGP signature
