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

[Michael Stapelberg]

Thanks for the good tips! Answers inline:

On Sun, Jan 22, 2017 at 8:59 PM, Andreas Beckmann <anbe at debian.org> wrote:
> 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)

Done.

>
>> 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

Done.

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

The timeline is not necessary for my use-case, so I will just use the logfile.

>
>> 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?

A simple package to test with is “vim”, which installs a couple of
diversions and slave alternative links.

A more interesting one is “dkms”, which depends on gcc and cpp. Only
gcc/cpp install alternatives, dkms itself doesn’t, resulting in lines
such as:

  LOG-ALTERNATIVES: dpkg=gcc: piuparts=dkms:
/usr/bin/update-alternatives --quiet --install /usr/bin/c89 c89
/usr/bin/c89-gcc 20 --slave /usr/share/man/man1/c89.1.gz c89.1.gz
/usr/share/man/man1/c89-gcc.1.gz

I also tested with “fonts-ipafont-gothic”, which calls
update-alternatives from a shell function. “wesnoth” has a rather long
update-alternatives invocation. I couldn’t find/think of any other
interesting cases.

If the patch works for you, could you merge it and apply it on
piuparts.d.o please? Thank you!

-- 
Best regards,
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Add-log-alternatives-custom-script.patch
Type: text/x-patch
Size: 2709 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/piuparts-devel/attachments/20170122/bb34961e/attachment-0001.bin>