Simon McVittie writes:
> 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.

Well, people don't like the simpler solution that someone else
proposed...

> 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.

Migrating /{s,}bin involves far fewer packages (only ~200 binary
packages).  There is still /lib though.

> 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.

You will always have this problem with partial upgrades unless *every*
package depends on a package that would ensure that the system has all
binaries previously in /bin also in /usr/bin.

In particular, if we want to treat this as a (release critical) bug,
iptables or any other package ever moving from /bin to /usr/bin (or the
other way) will always be buggy, regardless of any merged-/usr.  Same
for any binary ever moving between .../bin and .../sbin.

Ansgar

Reply via email to