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

[Michael Stapelberg]

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