Bug#1020792: tech-ctte: Halt merged-/usr transition until dpkg filesystem damage bugs are fixed
On Tue, Sep 27, 2022, at 12:25 PM, Andreas Metzler wrote:
> On 2022-09-27 Zack Weinberg <zack@owlfolio.org> wrote:
> [...]
>> What I am asking for is a schedule change: specifically, that the
>> merged /usr transition not be allowed to proceed past the status quo
>> as of two weeks ago (i.e. *before* init-system-helpers added a
>> dependency on usrmerge|usr-is-merged) until after the dpkg bugs are
>> fixed to the satisfaction of the dpkg maintainers.
> [...]
>
> Hello Zack,
>
> Afaiui the only thing the change two weeks caused is an increased
> percentage of usrmerged Debian installations.
It is *conceivable* that a system that has been *converted* to
merged-/usr, in the way usrmerge does it, is different from a system
that was originally installed with merged /usr, in a way that matters
to whether the dpkg bugs can be triggered on that system. I thought I
had come up with just such a scenario yesterday, in fact. On further
consideration I was wrong -- but that doesn't mean there are no such
scenarios.
However:
> Afaict the problem is unchanged: There is a very large number of
> usrmerged systems (every system installed with bullseye installer or
> newer unless some very specific steps were taken to avoid this) which
> are prone to bugs due to dpkg not having been changed *first*. This
> number is of usrmerged systems is so large that we cannot mark them as
> unsupported ("Please reinstall"). Whether this percentage is 25% or 90%
> does not matter.
I basically agree with this assertion. For instance, I think it's not
realistic to roll back every such system to an un-merged state, and
then restart the entire transition, this time following the procedure
that was used when /usr/man was moved to /usr/share/man, which is, it
appears to me, what Guillem would ideally like to have happen.
(I will point out, though, that if we had done it that way starting in
2015 or even 2017, *we would be done by now*, since that process takes
exactly three releases to complete.)
If I had had the authority to make the relevant decision at the time,
I probably would have insisted on getting the dpkg bugs fixed before
the installer's default could be changed. But that ship has sailed.
However, I think there's still value from a process-management
perspective in declaring that non-merged systems may not be converted,
and are to remain supported, until all critical components of the
distribution -- in particular dpkg -- fully support the merged state.
For instance, it means that the proponents of the transition have a
concrete incentive to get *all* of the remaining work done, and not
just the piece that matters to them.
zw
Reply to: