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

[Michael Stapelberg]

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
cat >/usr/bin/update-alternatives <<'EOT'
#!/bin/sh
echo "LOG-ALTERNATIVES: dpkg=${DPKG_MAINTSCRIPT_PACKAGE}:
piuparts=${PIUPARTS_OBJECTS}: $0 $@"
exec /usr/bin/update-alternatives.orig "$@"
EOT
chmod +x /usr/bin/update-alternatives

==> custom-scripts/scripts-log-alternatives/post_install_log_alternatives <==
#!/bin/sh

[ ! -e /usr/bin/update-alternatives.orig ] && exit 0
mv /usr/bin/update-alternatives.orig /usr/bin/update-alternatives

The resulting log lines look like this example:

    LOG-ALTERNATIVES: dpkg=vim: piuparts=vim:
/usr/bin/update-alternatives --install /usr/bin/vi vi
/usr/bin/vim.basic 30 --slave /usr/share/man/fr/man1/vi.1.gz
vi.fr.1.gz /usr/share/man/fr/man1/vim.1.gz --slave
/usr/share/man/it/man1/vi.1.gz vi.it.1.gz
/usr/share/man/it/man1/vim.1.gz --slave /usr/share/man/pl/man1/vi.1.gz
vi.pl.1.gz /usr/share/man/pl/man1/vim.1.gz --slave
/usr/share/man/ru/man1/vi.1.gz vi.ru.1.gz
/usr/share/man/ru/man1/vim.1.gz --slave /usr/share/man/ja/man1/vi.1.gz
vi.ja.1.gz /usr/share/man/ja/man1/vim.1.gz --slave
/usr/share/man/man1/vi.1.gz vi.1.gz /usr/share/man/man1/vim.1.gz

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

On Sun, Jan 22, 2017 at 4:49 PM, Michael Stapelberg
<stapelberg at debian.org> wrote:
> On Sun, Jan 22, 2017 at 3:41 PM, Andreas Beckmann <anbe at debian.org> wrote:
>> On 2017-01-22 14:43, Michael Stapelberg wrote:
>>> Thanks for the review! Answers inline:
>>
>> I'm thinking about making this more generally useful.
>>
>> For the piuparts command you want something like
>>
>>   piuparts ... --copy-file-from-chroot <filename-inside-chroot>
>> <filename-outside-chroot>
>>
>> I don't think exporting more than one file is feasible with a
>> master-slave setup.
>
> Why? The current patch exports any number of files, so clearly it’s
> technically possible. What makes you say that it’s not feasible?
>
>>
>> Then you could implement *anything* via custom scripts inside the
>> chroot, e.g. exporting the alternatives in
>> pre_install_export_alternatives, post_install_export_alternatives and
>> build a final single tarball in post_purge_export_alternatives.
>> Report the md5sum of the export file from post_purge_export_alternatives
>> (just in case something gets mixed up later on).
>> If you need extra packages in the chroot for these scripts, use
>> --fake-essential-packages
>>
>> These scripts would be given with an extra
>>   --scriptsdir /etc/piuparts/scripts-export-alternatives
>>
>> The slave should send the aux file immediately before the corresponding
>> log file and after sending logs for a section delete all unknown aux
>> files. aux files without log file should be deleted, not sent to master.
>>
>> master-bin/archive_old_logs should also handle old aux files.
>>
>> piuparts-slave should only pass the --copy-file-from-chroot option (or
>> however it is named) if the section is set up for exporting some stuff
>> The filename-inside-chroot should come from the section config.
>> The filename-outside-chroot should be generated by piuparts-slave, in
>> the package_version.extension format, the extension being something
>> general like .blob, don't assume a special format like .tar.xz.
>> By default this new feature should be disabled.
>
> This implies that the URL on piuparts.d.o would be something like
> /sid/libva1_1.7.3-2-aux.blob, correct? If so, I’m confused. How
> exactly would we deploy the alternatives-extraction on piuparts.d.o in
> such a way that other such steps can be added in the future?
>
>>
>> For the final patch I would probably want to see it as a series of
>> commits e.g. master-slave protocol support, piuparts support, glueing it
>> together.
>>
>> I expect this will be a project for buster, not stretch, I don't want to
>> hurry this into piuparts for stretch.
>
> Which version of piuparts is generally running on piuparts.d.o? I.e.,
> will the deployment of this change have to wait for the stretch
> release?
>
> --
> Best regards,
> Michael



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