On Thu, 29 Nov 2018 at 18:34:42 +0100, Ansgar Burchardt wrote:
> Regardless of debootstrap defaults or flag days, we could also consider
> moving programs from /{s,}bin to /usr/{s,}bin with a compat symlink in
> /{s,}bin
I'm not convinced this is a good idea: it seems like it causes as many
problems as it solves. It's effectively a gradual implementation of
making merged /usr mandatory, with a lot of moving parts (places where
it could go wrong) and a lot of packages and maintainers needing to be
involved, but without the simpler end result of *actually* merging /usr.
We've been migrating from non-multiarch to multiarch for more than 5
years and have still not got there, so I'm not confident that ad-hoc
migration from unmerged to merged /usr would go any quicker.
It can also cause the same failure modes with hard-coded executable paths
as merged /usr. Let's suppose we migrated grep from /bin to /usr/bin in
the way you suggest during the Debian 11 release cycle. If a package that
hard-codes the compile-time grep path (again, consider gzip, #914907)
is built with the new grep, it won't work correctly with the old grep
during a partial upgrade from Debian 10 to 11; but I don't see how it
would pick up a versioned Depends on the new grep without manual action
from the dependent package's maintainer, which isn't going to scale well.
> Debian is not responsible how third parties build their packages. We
> don't even exclude /usr/local/bin from PATH when building packages...
In particular, if you have a /usr/local/bin/grep, the same packages that
would hard-code /usr/bin/grep when built on a system with merged /usr
(for example gzip, #914907) will instead hard-code the path to your
/usr/local/bin/grep, resulting in them not working properly on systems
that don't have /usr/local/bin/grep. So perhaps bugs of the same class
as #914907 were already bugs in the source package before merged /usr
was ever suggested?
(To be fair, debuild(1) does sanitize PATH, but it's true that
dpkg-buildpackage doesn't.)
smcv
