On Tue, Sep 27, 2022, at 12:25 PM, Andreas Metzler wrote: > On 2022-09-27 Zack Weinberg <z...@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