[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Is there still a point in installing libgcrypt to /lib instead of /usr/lib



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


Reply to: