Re: dpkg-logger 1.0.5
>> "JG" == Jason Gunthorpe <jgg@ualberta.ca> writes:
JG> Anyhow.. I'm not entirely sure I like the use of syslog for
JG> logging. In fact I'm pretty sure I don't like it. It would make
JG> more sense for logging to be under control of the invoking GUI so
JG> the log could be siphoned off and displayed in real time if the
JG> user wished.
The deb-log versio sent is just one possibility. Apt or whatever can
bring its own. Or it can tail -f the logfile.
Someone else said that this would fail, if syslogd is not
running. This has to be considered as well. I envision something like
this:
1. *inst scripts only make output, that is important,thus worth to be
logged. This way, we can capture all output of a *inst script, one
doesn't have to use deb-log explicitly in the *inst scripts
(the scripts shouldn't make any unneeded output already)
2. The standard deb-log would just output to screen. This way, it
doesn't depend on a running or installed syslogd
3. There is another deb-log, which also has the capability to log to
syslog. It should only be used, when syslogd is installed and
running, it has to be deactiveted during (re)installation of
syslogd.
-- deb-log behaviour until we decided on an
interactive/non-interactive split of *inst split
4.1.1 output to screen (so we can do the interactive
configuration). Log to syslog as well for later reference.
-- deb-log after we have decided on an
interactive/non-interactive split of *inst split; For
compatibility, any script is considered interactive until
stated otherwise
4.2.1 On the non-interactive part, output to log.
4.2.2 On the non-interactive part, output to screen and to log (for
later reference).
--
5. The user can explicitly state for each part if the output should go
to log and/or screen using a conffile (/etc/deb-log.conf)
6. Other deb-log mechanism are possible (log to a sql database or
such)
7. The user and high-level installation programs can choose the
deb-log mechanism using the Debian alternatives mechanism
8. Hopefully I didn't forget something :-)
JG> I also don't like that the caller has to specify the package name
JG> explicy, it would make much more sense if that was deduced
JG> automatically (hax0r dpkg?)
Yes, I also think this is somewhat redundant. This is repetitive (thus
per definition errorprone to typos), so a computer should do this on
its own.
I made showed a way to find out the name, but as Ben pointed out, it
depends on procfs. I don't know any other.
Ciao,
Martin
Reply to: