Bug#914897: debating the wrong thing

[Ansgar Burchardt <ansgar@debian.org>]

Gunnar Wolf writes:
> Adam Borowski dijo [Mon, Dec 03, 2018 at 12:36:29AM +0100]:
>> (...)
>> So, let's enumerate possible outcomes:
>> 
>> 1. no usrmerge
>>   1a. no moves at all (no effort needed!)
>>   1b. moves via some dh_usrmove tool, until /bin is empty
>> 2. supporting both merged-usr and unmerged-usr
>> 3. mandatory usrmerge
>>   3a. by Bullseye
>>   3b. by Buster
>> 
>> Unless the TC decides for 2., all this work will be a pure waste of yours
>> and maintainers' time.
>
> ...One thing I fear here, that's also not being clearly debated AFAICT
> (although the "urgency" of this report points in the right direction)
> is that if the TC decides towards anything but 2 or 3b, we will have a
> hard time reaching and following through the freeze targets proposed
> by the Release Team. Which is something we don't want.

I don't think this list is good as (2) doesn't say anything about the
question asked originally (the default) and (3a) doesn't say anything
about what happens for Buster.

Currently implemented is (2) + default to merged-/usr for new
installations.

Switching to (1) or (3a-with-no-support-in-buster) will mean merged-/usr
systems would no longer be supported.  In this case someone would have
to write a unusrmerge program to convert systems with merged-/usr to
systems with unmerged-/usr.

Such a program doesn't exist yet and is probably more complicated than
usrmerge: for example how would it know that a /sbin/iptables ->
/usr/sbin/iptables symlink would have to be created when unmerging the
system?  Moving files from /usr to / is also more likely to run out of
disk space (if separate partitions are used for /usr and /).

I'm not sure how long it would take to get this right and so agree that
(2) or (3b) or (3a-with-support-in-buster) are reasonable choices.

>> With 1a, 1b, 3a the result will be "revert the change in debootstrap" (in
>> 3a "for now").  With 3b you need some way to make sure existing systems are
>> converted (also with 3a except for far more time for testing).
>
> I agree with your assessment. There are still too many mails I haven't
> read, though, and I cannot commit my hypothetical vote so far, but I
> think the sanest way will be to revert the change in debootstrap.

So (2) with the default to non-merged-/usr or (3a)?

I'm not sure why (2) should not default to merged-/usr though.

Ansgar