Re: dpkg.log reworked
>> "BC" == Ben Collins <bmc@visi.net> writes:
BC> On Fri, Jan 01, 1999 at 10:46:59PM +0100, Martin Bialasinski wrote:
>> No, dpkg-log should. The user could set e.g to_screen=yes in
>> /etc/deb-log.conf or in an environment variable or such. This is a
>> better solution. The user can still see the messages, but he
>> additionally has control over the process how they are handled.
BC> There is no way that the log util could know every little detail
BC> that needs to be outputed.
If _all_ output by the *inst scripts is sent to deb-log, it has all the
data.
BC> Also there is still the need even for interactive installs to log
BC> to a file.
Sure. For now, deb-log would output to stdout. After the
interactive/non-interactive split, it would output to syslog for the
non-interactive part and output to stdout for the interactive one. If
the user wants it to (interactive_to_log=1 in /etc/deb-log.conf),
it would also log to the syslog.
Also note, that there is no need to change the *inst files a second
time to archieve the splited behaviour (so the change can be
smooth). When the split is done, there will be a way to determine
that a non-interactive setup is run (e.g. environment variable), so
deb-log automaticaly knows what to do.
BC> Only the package maintainer would know what needs to be sent to
BC> the screen and what needs to be logged, there is no
BC> one-size-fits-all solution.
As long as the installation process doesn't get split, we have to
output everything to stdout and additionaly log it.
Later, the non-interactive part will output to log and the interactive
one to stdout by default. The user can customize this.
The maintainer has to do the split on interactive / non-interactive,
so he still decides what gets output to which facility, with the user
beeing able to customize the output behaviour.
This is not that elegant as makeing the maintainer mark an output as
stout or log, but forcing a basically equal change two times on the
maintainer is not elegant either.
BC> With this setup the package could also do both, output to stdout
BC> and to the loging mechanism.
This is also possible with deb-log, it is more flexible as well, and
it is better preparing for the future.
These are the advantages of my proposal:
- only one change of *inst scripts necessary
- prepared for future changes (interactive / non-interactive)
- transition during the installation split is smooth, will work by
just splitting the script, no changes to output routines in *inst
- user has full control over output
Ciao,
Martin
Reply to: