[Piuparts-devel] Bug#850917: Please export /var/lib/dpkg/alternatives content after installation

[Andreas Beckmann]

On 2017-01-22 19:02, Michael Stapelberg wrote:
> After going a bit further down the road, I realized that the
> before/after tarballs of /var/lib/dpkg/alternatives are not as useful
> as I had assumed they would be: when installing non-trivial packages
> (with a bunch of dependencies), they contain changes caused by a
> number of different packages, whereas I need the changes of precisely
> one package.
> 
> Hence, I think using a custom script to log update-alternatives
> command lines is actually more useful:
> 
> $ head -50 custom-scripts/scripts-log-alternatives/*
> ==> custom-scripts/scripts-log-alternatives/pre_install_log_alternatives <==
> #!/bin/sh
> 
> # Do nothing if the script already ran.
> # The pre_install step can be run multiple times.
> [ -e /usr/bin/update-alternatives.orig ] && exit 0
> 
> mv /usr/bin/update-alternatives /usr/bin/update-alternatives.orig

use dpkg-divert s.t. this works in upgrade scenarios, too
(look at the existing scripts how I diverted stuff there)

> cat >/usr/bin/update-alternatives <<'EOT'
> #!/bin/sh
> echo "LOG-ALTERNATIVES: dpkg=${DPKG_MAINTSCRIPT_PACKAGE}:
> piuparts=${PIUPARTS_OBJECTS}: $0 $@"

you probably want to output that to a logfile and dump the logfile in
the post_remove, otherwise you'll miss

update-alternatives --foo bar >/dev/null 2>&1 || true

I would be surprised if no maintainer script does output redirection

(you could still log in on stdout as well - gives a better timeline, but
expect to miss some bits)

> exec /usr/bin/update-alternatives.orig "$@"
> EOT
> chmod +x /usr/bin/update-alternatives

> What do you think about this approach? Is that suitable for deployment
> on piuparts.d.o?

that should work quickly

I can try it in my instance, do you have any "interesting" packages in
mind for testing?


Andreas