On Wed, 2020-02-19 at 09:39 +0000, Simon McVittie wrote: > On Wed, 19 Feb 2020 at 09:31:51 +0000, Simon McVittie wrote: > > I agree that what Guillem is proposing also does not have the property, > > which I think is one that is important to you?, that the contents of the > > root directory are decoupled from /usr (can be set up by an initramfs > > or a container-runner, perhaps in a tmpfs, without detailed knowledge > > of the OS installation in /usr). > > Or perhaps Guillem is intending that in n years' time, when no package > in Debian (not even libc6!) ships files in /bin /sbin /lib* in its > data.tar.*, *then* the maintainer-script-maintained symlink farms in /bin > /sbin /lib* can be replaced by symlinks bin -> usr/bin, etc., without > this resulting in anything dpkg-managed being overwritten or aliased? > > If that's the case, then we get that desirable property *eventually* under > this proposal, but not any time soon.
As far as I know the path `/lib64/ld-linux-x86-64.so.2` is part of the ABI (and similar paths on other architectures). So that will have to exist unless we break the ABI. Therefore I assume this is unlikely to happen. I don't think updating *everything* to use `/usr/bin/sh` instead of `/bin/sh` and so on a practically implementable proposal, especially as any local or third party use would need to be updated as well. If you start creating symlink farms in bin/* to usr/bin/*, there is also the risk to get stuck in that state. AFAIR this might be the case with OpenSuSE (not sure, I think that was their state some time ago at least). Ansgar
