Re: piuparts output wishlist?
Lars Wirzenius <email@example.com> writes:
> How would _you_ like to see piuparts report results, and produce other
> output? Go wild, the sky is bright blue.
> The obvious things to fix are:
> - make it really easy to see what the result of each test is
Almost as obvious is to easily identify which test is being run.
This is kind of available now, but only if you know to look in the
‘DEBUG’ messages for command starts and exit status reports. I think
those debug messages are fine (provided the default logging level is
raised so those messages don't appear by default).
I think a good way to show both of these would be to have a different
channel of output, beside the logging output, that shows explicitly a
test identifier at the start, and then the result of that test at the
end, with a visually similar presentation for both. “Test identifier”
can simply be a command line, for example::
N: Running command: ‘dpkg --info /var/cache/pbuilder/result/burn_0.4.4-1_all.deb’
I: Command OK: ‘dpkg --info /var/cache/pbuilder/result/burn_0.4.4-1_all.deb’
N: Running command: ‘chroot /tmp/tmpQm3zr8 dpkg -i tmp/burn_0.4.4-1_all.deb’
E: Command FAILED: ‘chroot /tmp/tmpQm3zr8 dpkg -i tmp/burn_0.4.4-1_all.deb’
> - indicate severity of test failures (an extra file after purge is not
> not as severe as leaving a daemon process running)
I like the earlier suggestions of ‘I: ’, ‘N: ’, ‘W: ’, ‘E: ’ prefixes to
indicate these severities. (I would understand these as, in increasing
order of severity: “info”, “notice”, “warning”, “error”.)
> - make logs be rather less voluminous by default
Yes, the default log output level should be something like ‘NOTICE’.
\ “The most common way people give up their power is by thinking |
`\ they don't have any.” —Alice Walker |