Hi Simon, On Tue, Aug 17, 2021 at 05:19:06PM +0100, Simon McVittie wrote: > If we want to make buildd chroots merged-/usr any time soon, then I > think we need to say this class of bugs is RC for bookworm.
I fear there might be a logic trap here. For a moment, let us assume perfection of this plan: Reproducible builds identify all of the cases that need to be fixed. We bump them to RC bugs. We fix them all. Then we change unstable to be merged-/usr and we're done. Are we? We still need to support partial upgrades from bullseye to bookworm, so - as you pointed out earlier - all packages in bookworm will have to keep this support property. However, our defaulting to merged-/usr makes it impossible for reproducible builds to test it as producing an unmerged chroot is no longer possible. Effectively, the unmerged case will be untested and as a consequence will be broken. For this plan to work, we will have to support unmerged chroots until the end of bookworm, which appears to contradict the premise we started with. > This class of bugs applies equally to anything that makes an executable > available at both /bin/foo and /usr/bin/foo, so even if people want to > disregard the two Technical Committee resolutions on the subject of > merged-/usr and look for consensus around symlink farms in the root > filesystem instead, we'll probably still need to make sure bugs of this > class get fixed. You keep proposing adding /bin/foo -> /usr/bin/foo symbolic links via maintainer scripts. Indeed people are already adding such links. Unfortunately, the way they do it breaks DPKG_ROOT. It also undermines the work of Niels Thykier, myself and others to reduce the number of maintainer scripts in Debian. The collateral damage of the merged-/usr work to the work I'm interested in is huge. Would it be possible to add some central helper for the creation of these links such that I could fix this helper once instead of hunting down hundreds of copies of these DPKG_ROOT bugs with ever more being added? Or maybe we could even do this declaratively by adding a /usr/share/usr-merge.d/<package> file containing paths that need compat symlinks that would be instated by some essential package via triggers? We keep saying that Debian work is voluntary, but this is only true in theory, because Debian is about integrating and combining components. I would like to ignore merged-/usr, but the collateral damage has cost me at least a week already (mostly due to having broken dpkg-shlibdeps). The story is worse for Guillem Jover. We can assert that the current /usr-merge implementation is significantly hampering innovation by dumping work on people that would otherwise improve Debian. It is this aspect that makes me unhappy about merged-/usr. The support received from merged-/usr proponents with diagnosing and fixing issues is suboptimal. Yours disappointed Helmut
