On 2021-07-27 Wouter Verhelst <wou...@debian.org> wrote: > On Thu, Jul 22, 2021 at 03:20:05PM +0100, Simon McVittie wrote: >> On Thu, 22 Jul 2021 at 15:53:32 +0200, Wouter Verhelst wrote: >>> I've suggested previously that we can easily make it RC for bookworm to >>> have a file outside a limited set of directories (/etc and /usr would be >>> OK, but notably /bin /lib and /sbin wouldn't be) that is not a symlink. >>> This is easy to detect with a lintian check and reasonably easy to >>> implement
>> I don't think that works in general without breaking some of Debian's >> axioms around Essential packages, as previously described here: >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978636#118 > Yes. Those arguments didn't convince me then, and they don't convince me > now. > A package in the essential set could work around the issue by moving a > file around and creating a necessary symlink in preinst rather than > shipping things. The set of Essential packages is small however, and > most packages can ship a compat symlink. > I didn't say we *should* ship compat symlinks; I said we should make > antyhing that is *not* a compat symlink in a particular set of > directories be RC. [...] Hello Wouter, I will bite. just for context: Simon said in #978636 that e.g. coreutils a) cannot ship both /usr/bin/mv and /bin/mv (the latter a symlink) in the tarfile since /bin _might_ be a symlink to /usr/bin but b) it needs to provide /bin/mv in unpacked, unconfigured state. Simon then said we needed a flag day where the aliasing-symlinks /bin --> /usr/bin are either guaranteed to exist or forbidden. Once that is know essential packages either ship both /usr/bin/mv and /bin/mv (the latter a symlink) or only ship /usr/bin/mv (with no symlink required.) Afaiu you are suggesting to do somethink like this instead and immediately post bulleye release. ---------------------------------------- preinst upgrade|install if aliasing-symlinks /bin --> /usr/bin # do nothing else mv /bin/mv /usr/bin/mv ln -s /usr/bin/mv /bin/mv fi Plus corresponding error handling code in postrm abort install. ---------------------------------------- I just do not get the benefit. It seems rather complicated with potential for breakage in corner cases and unnecessary since we (CTTE) have essentially decided that there is going to be a cutoff date pre-bookworm-release whereupon package maintainers can rely on the existence of aliasing-symlinks and can simply move the file without any maintainerscripts. It seems to be a waste of work to write complicated maintainerscripts that are only needed as long as we need to handle both usrmerge-d and non-usrmerge-d systems. cu Andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure'
