On Tue, 26 Jan 2021 at 11:27:07 +0100, Bastian Blank wrote:
> Before unpacking those packages, both /bin and /lib symlinks must
> already exist, because it's past the cutoff date of non-aliased support.
I would like that to become true, but the cutoff date of non-aliased
support has not yet happened, and this bug is about making it
happen. *After* we have done that, we can consider mandating your 1b.
> Option 2 doesn't provide us any benefit. The world already implemented
> option 1.
I personally agree, and I hope the technical committee as a whole will too,
but I wanted to describe option 2 so that we can be clear about what we're
resolving and whether option 2 is it.
> We are already effectively at 1a. So we need to decide if we want 1b to
> fix the fallout.
We are *partially* at 1a: systems that were installed since the release
of buster are (unless steps were taken to avoid that), and systems that
have had usrmerge installed are, but other upgraded systems are not.
I'm typing this on a laptop that is still not merged-/usr, because I think
it's more likely that packages will work correctly on merged-/usr, and
if packages that I care about fail to work on a non-merged-/usr system,
I want it to happen to me, not to someone who is in a worse position to
debug it.
> > The only other option that I can see is for dpkg to gain the ability to
> > populate what we might call the "mergeable" directories (/bin, /sbin,
> > /lib*) in a purely declarative way, during unpack.
>
> No, because we want to support /usr only systems or snapshots, where /
> is populated on first boot.
Sure, and I'm not saying that this is the option that we should take
(in fact I think we should not do this), but it's an option that exists
and is possible. I think the reasons to reject it outweigh the reasons
to take it, but I want to be aware of all the options that exist, not
just the ones that are convenient for my own plans.
smcv
