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>). I did some bug-reporting for this during the bookworm cycle and I don't remember reporting any bugs where a package changed whether it installed /bin/foo or /usr/bin/foo (or sbin or lib* equivalents) according to whether it was built in a merged-/usr chroot or not: the bugs I was reporting were generally about file contents, not the file list. Most of the remaining merged- vs. unmerged-/usr differences have been packages that install an Autotools-generated Makefile into /usr/share/doc/PACKAGE/examples, like for example <https://bugs.debian.org/1021860> which says "EGREP = /bin/grep -E" when built in an unmerged-/usr chroot, but /usr/bin/grep in a merged-/usr chroot. That's annoying but not really a serious issue, because it's only an example file, and in my opinion should not be RC (but I would consider it potentially RC if the path was in a functionally-necessary file). If a package installs in the typical multiple-binary-package way: - make - make install DESTDIR=$(pwd)/debian/tmp - dh_install splits up debian/tmp using debian/*.install - dh_builddeb then a mismatch between the expected /bin/foo and a new /usr/bin/foo will generally cause FTBFS rather than a misbuilt package, because dh_install will fail to find /bin/foo. So I think the highest risks for this failure mode are going to be packages that use the simplified single-binary-package code path: - make - make install DESTDIR=$(pwd)/debian/my-package - dh_builddeb and packages that do not use debhelper in the conventional way. smcv