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
Attachment:
pgptjWLb2eobr.pgp
Description: PGP signature