Bug#994388: tech-ctte: More specific advice regarding merged-/usr and implications of #978636

[Simon McVittie <smcv@debian.org>]

On Mon, 27 Sep 2021 at 09:18:29 -0600, Sam Hartman wrote:
> [smcv wrote]
> >On merged-/usr systems, there is a possible failure mode involving files
> >being moved between packages (with Replaces) during the same release
> >cycle that their logical location is changed from the root filesystem
> >to the corresponding aliased directory in /usr, which can result in
> >the affected file disappearing. This can be avoided by not changing
> >the file's logical location until the beginning of the Debian 13
> >development cycle, after the transition to merged-/usr is complete.
>
> I don't understand how transitioning files in the Debian 13 cycle is
> going to work any better than in the Debian 12 cycle unless dpkg happens
> to change.

I think you might be right about this.

It might not be possible to do these changes of logical location without
first enhancing dpkg to understand that certain directory hierarchies
are aliases for each other.

Or, perhaps it can work in a subset of cases, and people with an interest
in merged-/usr can identify patterns that are safe, and have guidance
that recommends sticking to those patterns?

(For example we might need to require that if files that were historically
in /bin, /sbin, /lib* are moved between packages, then either there's some
sequencing requirement enforced by Pre-Depends/Conflicts to make sure the
/usr move is done before the ownership change, or the files do not move to
/usr until the next release cycle? I haven't thought this through, I'm just
saying these as examples of things that people who do the detailed design
might try.)

Do we want to specifically say in our advice that proponents of merged-/usr
are invited to design solutions for this?

The Technical Committee does not do detailed design, so I think identifying
specific patterns that are safe is not our job - but if domain experts
identify good patterns, and ask us to check their working and then issue
advice recommending those patterns, we can do that.

    smcv