<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 7 Oct 2022, 21:45 Simon McVittie, <<a href="mailto:smcv@debian.org">smcv@debian.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, 07 Oct 2022 at 18:07:45 +0100, Luca Boccassi wrote:<br>
> Wouldn't it be sufficient to create the build2 chroot as merged-usr<br>
> from the start?<br>
<br>
That would also be fine, but I think the way the reproducible-builds<br>
infrastructure works is that it caches a single (non-merged-/usr)<br>
pbuilder tarball per suite and converts it to merged-/usr on-demand<br>
for build2, to avoid having to cache essentially the same content twice.<br>
The important thing here is that one of the two builds should be<br>
merged-/usr, and the other should not.<br>
<br>
Having a merged-/usr pbuilder tarball and unmerging it with<br>
dpkg-fsys-usrunmess for one of the two builds would also work, but I<br>
suspect that would be less reliable than starting from non-merged-/usr and<br>
merging one of the builds but not the other.</blockquote></div></div><div dir="auto"><br></div><div dir="auto">In this particular case, it would seem to me that it would be best to optimize for correctness and safety (and less engineering cost) rather than disk space saving?</div><div dir="auto"><br></div><div dir="auto">Kind regards,</div><div dir="auto">Luca Boccassi </div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br>
</blockquote></div></div></div>