[Piuparts-devel] Bug#850917: Bug#850917: Please export /var/lib/dpkg/alternatives content after installation
Holger Levsen
holger at layer-acht.org
Mon Jan 23 11:09:11 UTC 2017
Hi,
thanks for your work on this. It looks pretty good already.
On Sun, Jan 22, 2017 at 03:41:22PM +0100, Andreas Beckmann wrote:
> I don't think exporting more than one file is feasible with a
> master-slave setup.
while Michael has shown it's feasible, I wonder if this doesn't cause
too much overhead and fragility and whether we shouldn't transmit a
default tarball, which then in turn can contain several payloads?
aux_$pkg_$version.tgz and that has arbitrary (defined) contents…
(on or more tarballs again)
> Report the md5sum of the export file from post_purge_export_alternatives
> (just in case something gets mixed up later on).
I like that idea…
> 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.
agreed on the last part which makes the first part mandatory :) (I
slightly dislike sending the aux file before the log file…)
> master-bin/archive_old_logs should also handle old aux files.
indeed.
> 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'd also like several commits for this, if/where sensible.
> I expect this will be a project for buster, not stretch, I don't want to
> hurry this into piuparts for stretch.
Here I disagree: I plan to upload 0.75 tomorrow or latest on wednesday
(not thursday) and let it migrate to stretch. After that, I'll be happy
to merge Michael's work on this and will/would like to include it in
0.76. And then, assuming the freeze lasts longer than a month or two,
I'll probably ask the release time to accept 0.76 into stretch, and will
be happy with whatever they'll decide.
During all this, piuparts.d.o will continue running code from the
develop branch, so this code should be running there as soon as it has
been merged.
That said, I neither want to hurry this in. I want this in, when it's
ready. :)
--
cheers,
Holger
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/piuparts-devel/attachments/20170123/53cff587/attachment.sig>
More information about the Piuparts-devel
mailing list