[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: logging for package installs



On Thu, Jul 03, 2003 at 05:38:46PM -0400, Joey Hess wrote:
> 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.

That would be really great, and I'm quite entousitastic about the idea.

> 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.

Check the log4j project, they did come up with a really great logging
framework. Of course, their code isn't usable at all (that's java), but
their concept are very advanced. Applying this to dpkg-log would allow the
user to provide the format they want, depending of the kind of message and
its gravity.

For that, we kind of need a standardization of the possible categories.
Using package name as categorie seems underoptimal to me since it won't be
useable from the user point of view. We could use the sections for that.

 dpkg-log --category main/doc --level critical "Hey, this version will \
  break your install, erase your data and kill your mum unless you check \
  README.debian carfully"

or the tags

 dpkg-log --category gnome --level minor "subliminal message: Gnome rulez"

or a mix of the two, but that may be hard to do right.

> Nor have I thought about l10n at all.

You'll have a bad time i18ning that. The problems with debconf template
i18ning was that:
 - the translation must be there before the program install
 - the texts are short and dispatched over all packages, making the ratio of
   translator work between actual translation work and administrative work to 
   get their work included rather bad.
   
With dpkg-log messages, you'll get into those two problems too, plus the
fact that I guess that maintainers will want to add variating text like
  errmsg=`run a command`
  if [ $? != ] ; then
    dpkg-log $"Damnit the execution of this command failed with the message $errmsg"
  fi

The errmsg stuff is impossible to translate unless setting LC_ALL for the
execution program run, but this leads to other problems if you want to parse
the output... 

I can't find a good way to translate those errmsg stuff, but for the others,
I think that it could be pushed to the debian/po file. debian/po/POTFILE.in
provides a provision for such extends. I need to speak with Denis Barbier to
see how we could this happen in the po-debconf and po4a realm.

> 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.

Fully agreed.
 
> 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.

I want to help on this, please keep me informed !

Bye, Mt.

-- 
Si vous pensez que l'éducation coûte cher, essayez l'ignorance.
  -- Albert Einstein



Reply to: