On Thu, 19 Aug 2021 at 10:06:27 +0200, Helmut Grohne wrote: > You keep proposing adding /bin/foo -> /usr/bin/foo symbolic links via > maintainer scripts.
I'm not proposing this! I'm trying to *not* need to do that in any more packages, and instead do usrmerge or equivalent, so that individual packages' maintainers don't have to take per-package action to move their files from /bin,/sbin,/lib* into /usr while creating compatibility symlinks for non-merged-/usr systems. However, I know Guillem and some others object to that strategy, so I'm trying to also be clear about which of the fixes that are necessary with usrmerge would be equally necessary for a symlink-farm-based strategy, if people who prefer a symlink-farm-based strategy gain consensus for that strategy. Exactly how the symlinks in a symlink-farm-based strategy are created is orthogonal to whether packages need to avoid hard-coding (e.g.) /bin/env or /usr/bin/sh, in filesystem layouts where both paths with and without /usr exist, which would break the installation of that package onto the traditional filesystem layout where only /usr/bin/env and /bin/sh exist. I agree that if a symlink-farm-based strategy is used, then delegating the creation of the individual symlinks to individual packages' maintainer scripts has practical problems, and it would be better to centralize the creation of those symlinks (somehow). I think it's up to the people who want to generate symlink farms to solve that problem. Note that what the Technical Committee resolved as the desired state is merged /usr with aliasing symlinks such as /bin -> usr/bin, not a symlink farm with individual symlinks such as /bin/sh -> /usr/bin/sh, precisely because we are concerned about the number of "moving parts" involved in setting up a symlink farm. (Speaking for myself here, not for the TC, but I don't think I'm misrepresenting anyone's position on the symlink farm approach by saying this.) > The collateral damage of the merged-/usr > work to the work I'm interested in is huge. In this specific case, I think the thing you're having a problem with is the gradual, file-by-file migration of executables into /usr by individual packages and individual packages' maintainers. That's not merged-/usr: merged-/usr does the migration all at once, by creating the aliasing symlinks (and then we can clean up the contents of data.tar.* to put all /usr-like files below /usr at our leisure, during the next release cycle, without needing maintainer script glue). The aliasing symlinks create problems for dpkg, as Guillem has documented elsewhere, and as a result some people are pursuing a symlink-farm-based alternative to the aliasing symlinks. If that symlink-farm-based approach is taken, then yes, we will need either a centralized mechanism to construct those symlink farms, or a lot of maintainer script glue (and, again, the Technical Committee's recommendation was to not do that). The packages that needed maintainer-script changes *before* merged-/usr, in order to enable merged-/usr, are those that previously shipped files at both /foo and /usr/foo in their data.tar.*, such as coreutils (<< 8.24-1) for /{usr/,}bin/touch. The reason they need maintainer script code is that we still support non-merged-/usr systems; their maintainer scripts are a no-op on merged-/usr systems, so if the bookworm release only supported merged-/usr, then their maintainer script code could disappear during the bookworm+1 cycle. I agree that *those* maintainer scripts are creating extra work for people working on DPKG_ROOT and similar things, and would not have been necessary if we had not gone in the direction of merged-/usr in around 2016. If we can make those unnecessary, or more declarative, then that would be a good direction. smcv