Bug#708830: dpkg: colourise dpkg output

[Christoph Anton Mitterer]

Package: dpkg
Version: 1.16.10
Severity: wishlist


Hi.

May I suggest to add optional colourisation of dpkg's output (perhaps even making the
colours configurable per category).

Non only on dist-upgrades but also on day-to-day's upgrades (especially for those people
using sid) one sees countless of lines of "standard dpkg output", most prominently things
like:
- Preparing to replace foo 1.0 (using .../foo_2.0-1_amd64.deb) ...
Unpacking replacement foo ...
- Setting up foo (2.0-1) ...

but also the less oftem messages like:
- (Reading database ... ?%
- Processing triggers for ?


Quite frankly, these are usually boring... as (usually) nothing interesting happens on
them.
So I'd suggest to take a "less visible" colour for like grey.
I could however imagine to emphasise some of the information of these lines, which are
at least a bit interesting in normal cases, like for:
- Preparing to replace foo 1.0 (using .../foo_2.0-1_amd64.deb) ...
Unpacking replacement foo ...
- Setting up foo (2.0-1) ...
=> the package name and version (not the deb file path)

or for
- Processing triggers for ?
=> the kind of triggers (e.g. man-db, doc-base or whatever)

For these I'd use bold or a bit lighter (or darker grey).



Now back to the main problem,... as all these messages from above have the same colour
right now, than everything else,... it can easily happen, that really important and/or
interesting messages are overseen in them.
Examples:
1) Output from the maintainer scripts:
...
Setting up openjdk-7-doc (7u21-2.3.9-4) ...
Setting up openjdk-7-jre-headless:amd64 (7u21-2.3.9-4) ...
update-binfmts: warning: current package is openjdk-7, but binary format already installed by openjdk-6
Setting up openjdk-7-jre-lib (7u21-2.3.9-4) ...
Setting up openjdk-7-jre:amd64 (7u21-2.3.9-4) ...
Setting up openjdk-7-demo (7u21-2.3.9-4) ...
...
or
...
Setting up librpmsign1 (4.10.3.1-1) ...
Setting up rpm (4.10.3.1-1) ...
Setting up man-db (2.6.3-5) ...
Updating database of manual pages ...
Setting up libgmpxx4ldbl:amd64 (2:5.1.1+dfsg-3) ...
Setting up libppl12:amd64 (1:1.0-6) ...
Setting up libppl-c4:amd64 (1:1.0-6) ...
...
2) config files changes
Setting up libreoffice-style-tango (1:4.0.3-1) ...
Setting up libreoffice-common (1:4.0.3-1) ...
Installing new version of config file /etc/libreoffice/sofficerc ...
Setting up libreoffice-java-common (1:4.0.3-1) ...
Setting up libreoffice-base (1:4.0.3-1) ...
3) files that couldn't be created/removed/etc.
Preparing to replace python2.7-minimal 2.7.3-8 (using .../python2.7-minimal_2.7.5-1_amd64.deb) ...
Unpacking replacement python2.7-minimal ...
dpkg: warning: unable to delete old directory '/etc/python2.7': Directory not empty
Selecting previously unselected package libpython2.7-minimal.
Unpacking libpython2.7-minimal (from .../libpython2.7-minimal_2.7.5-1_amd64.deb) ...
4) newly installed packages and package removals
...
Selecting previously unselected package libxtables10.
Unpacking libxtables10 (from .../libxtables10_1.4.18-1_amd64.deb) ...
...
respectively
...
Removing libprocps0:amd64 ...
Purging configuration files for libprocps0:amd64 ...
...
=> Well in principle these are the same "boring" standard messages than those from upgrade,
the difference is that (usually) there are far less packages removed/installed than
upgraded. So it might be a good idea to allow thes lines be coloursed (at best via some
configuration, whether or not)... maybe it's also good to just colourise the important
words like "Removing" and/or "Purging" instead of the whole lines


So if that was ever implemented, I'd perhaps suggest the following general ideas:
- The "boring" output should be grey per default, with the more interesting parts of them
(package names, version numbers - see above) some very similar grey (darker, lighter, bold or
something like that).
- Output from the maintainer scripts to stdout, should be (per default) the default colour,
i.e. not changing the colour of that at all. This is usefull, as that might be even already
colourised.
- Output from the maintainer scripts to stderr should be red.
- Error ouput from dpkg (like (3) above) should be perhaps purple.
- Informational output like e.g. (2) above should perhaps be cyan.
- etc. pp..
- output that is not categorized should be considered "interesting" and get perhaps the colour
orange (or I guess brown is the most similar colour on the console).


Cheers,
Chris.


--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

[Jonathan Nieder]

Hi,

Christoph Anton Mitterer wrote:

> - Preparing to replace foo 1.0 (using .../foo_2.0-1_amd64.deb) ...
> Unpacking replacement foo ...
> - Setting up foo (2.0-1) ...
>
> but also the less oftem messages like:
> - (Reading database ... ?%
> - Processing triggers for ?
>
> Quite frankly, these are usually boring... as (usually) nothing interesting happens on
> them.

I wonder if this is a sign that dpkg is too noisy. It's often hard to
see real warnings from maintainer scripts admid the normal dpkg noise.
Would it make sense to skip the "Unpacking" message, for example,
since it is not necessary for figuring out which maintainer script
produced a given message?

I also wonder if frontends have enough information to do the
coloration you're asking for without parsing output lines. Can
frontends pass an argument to suppress messages that are redundant
next to information that was sent to the --status-fd?

Curious,
Jonathan

[Guillem Jover]

On Sun, 2013-05-19 at 23:50:56 -0700, Jonathan Nieder wrote:
> Christoph Anton Mitterer wrote:
> > - Preparing to replace foo 1.0 (using .../foo_2.0-1_amd64.deb) ...
> > Unpacking replacement foo ...
> > - Setting up foo (2.0-1) ...
> >
> > but also the less oftem messages like:
> > - (Reading database ... ?%
> > - Processing triggers for ?
> >
> > Quite frankly, these are usually boring... as (usually) nothing interesting happens on
> > them.
>
> I wonder if this is a sign that dpkg is too noisy. It's often hard to
> see real warnings from maintainer scripts admid the normal dpkg noise.
> Would it make sense to skip the "Unpacking" message, for example,
> since it is not necessary for figuring out which maintainer script
> produced a given message?

I think there's already a request to add support for --quiet, which
would get rid of most of the point of this bug report.

> I also wonder if frontends have enough information to do the
> coloration you're asking for without parsing output lines. Can
> frontends pass an argument to suppress messages that are redundant
> next to information that was sent to the --status-fd?

Hmm, perhaps with some smart interception. It would be easier to do it
from dpkg itself. Although if this is to be implemented it really does
will have very low priority. I'll have to think about it in any case.

Thanks,
Guillem