On Sun, Jan 22, 2017 at 3:41 PM, Andreas Beckmann <a...@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
