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
