On 2023-07-16, Simon McVittie wrote: > On Sat, 15 Jul 2023 at 18:27:24 +0200, Adam Borowski wrote: >> But, what matters here is the CTTE ruling in #1035831 -- for the time being, >> packages must not move files between locations affected by the aliasing. > > If that happens in reality, then yes, that's bad, and reverting the change > is a mitigation. What packages have this behaviour? > > We are going to need to bring back this change relatively early in the > trixie cycle in any case, for the reasons given in the commit message. > I have not yet analyzed whether we need this change before we can lift > the moratorium on file moves, but I suspect we might. > >> Packages built in an usrmerged chroot place such files under /usr while >> built without usrmerge into whatever place they were installed to -- which >> is a direct breach of the ruling. > > Do you have examples of packages that differ in this way when built in > a merged- or unmerged-/usr environment? I think we should treat this > as a RC-for-trixie bug in those packages (and in fact I would have been > tempted to call it RC for bookworm as well, again for the reasons given > by the TC, even though during the trixie cycle it was mitigated by using > unmerged-/usr fro buildds). > > During most of the bookworm cycle, https://reproducible-builds.org/ has > been doing "build1" in unmerged-/usr and "build2" in merged-/usr, with > differences tracked in > <https://tests.reproducible-builds.org/debian/issues/unstable/paths_vary_due_to_usrmerge_issue.html> > (that list is not necessarily complete, there can also be unidentified > differences in > <https://tests.reproducible-builds.org/debian/unstable/amd64/index_no_notes.html>). For what it is worth, there were various points during the bookworm cycle where this was not being tested on reproducible builds infrastructure, as the mechanisms to disable it changed several times... We used to just be able to build a non-usrmerge tarball, and then install usrmerge in the second build, but I think usr-is-merged or some similar package is installed out of the box now, and the inverse operation is non-trivial. ... which lead to some of the identified issues being systematically removed for packages that were otherwise reproducible (you could still look through git history to find more, but some many may be actually fixed). There are differing opinions on weather reproducible builds test infrastrure should test usrmerge variations at all, given the direction of Debian, though any alternate test infrastructure would essentially have to implement a reproducible builds style test to check for differences... After upgrading the infrastructure to bookworm, testing usrmerge variations broke again, and so is currently disabled... though I have configured the paths_vary_due_to_usrmerge issue so that old known issues are not automatically removed anymore. live well, vagrant
Attachment:
signature.asc
Description: PGP signature