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

[David Bremner]

Simon McVittie  writes:

> I'm calling for votes on the following resolution as formal advice from
> the Technical Committee (Constitution §6.1.5). There are no non-accepted
> amendments, so the options to vote on are "yes" or "further discussion".
>
>  begin text to be voted on 
>
> Summary
> ===
>
> There are currently Debian 11 installations with both the merged-/usr and
> non-merged-/usr filesystem layouts. All of these installations should
> successfully upgrade via normal upgrade paths to a merged-/usr Debian 12.
> Only after the release of Debian 12 can packages assume that all
> installations will be merged-/usr.
>
> Main points:
>
> - We have recommended merged-/usr for Debian 12.
> - Moving individual files is not merged-/usr.
> - "Symlink farms" are not merged-/usr.
> - Upgrading a non-merged-/usr system to Debian 12 needs to work.
> - Upgrading a merged-/usr system to Debian 12 needs to work.
> - Packages cannot assume all systems are merged-/usr until the Debian 13
>   development cycle begins.
> - Upgrading via apt in the usual way should work.
> - Testing and QA systems should be able to avoid this transition, but if
>   they do, they cannot be upgraded beyond Debian 12.
> - A package building incorrectly on a non-merged-/usr system is a bug.
> - A package building incorrectly on a merged-/usr system is a bug.
> - Please stop moving individual packages' files from the root filesystem
>   into /usr, at least for now.
>
> Definitions and current status
> ==
>
> libQUAL refers to the directories described in FHS 3.0 section 3.10 [1],
> such as lib64 on the amd64 architecture.
>
> Merged /usr is the filesystem layout in which /bin, /sbin, /lib and each
> /libQUAL that exists are symbolic links to the corresponding directories
> below /usr. This results in aliasing between /bin and /usr/bin, and
> so on.
>
> In the merged-/usr layout, files whose canonical logical location is
> in one of the affected directories on the root filesystem, such as
> /bin/bash, /sbin/fsck and /lib/ld-linux.so.2, are physically located at
> the corresponding path below /usr, such as /usr/bin/bash. Each file in
> one of the affected directories is accessible via two paths: its canonical
> logical location (such as /bin/bash or /usr/bin/env), and the other path
> implied by the aliasing (such as /usr/bin/bash or /bin/env).
>
> There are two supported categories of Debian 11 installation, which are
> currently considered equally-supported:
>
> - Merged-/usr installations. These were installed with debian-installer
>   from Debian 10 or later, or installed with debootstrap --merged-usr,
>   or converted from the non-merged-/usr layout by installing the usrmerge
>   package, or installed or converted by any similar procedure. They have
>   the merged-/usr layout.
>
> - Non-merged-/usr installations. These were installed with debian-installer
>   from Debian 9 or earlier and subsequently upgraded without converting
>   to merged-/usr, or installed with debootstrap --no-merged-usr, or
>   converted from the merged-/usr layout with dpkg's "dpkg-fsys-usrunmess"
>   utility or any similar procedure. They have the traditional,
>   non-merged-/usr layout in which /bin/bash and /usr/bin/env have exactly
>   those physical paths, and /usr/bin/bash and /bin/env do not exist.
>
> Merged-/usr is not the only filesystem layout that has been proposed for
> unifying the root filesystem with /usr. For avoidance of doubt, we do not
> consider other filesystem layouts to be implementations of merged-/usr.
> In particular, we do not consider these to be implementations of merged-/usr:
>
> - all affected files physically located in /bin, /sbin, /lib and /libQUAL,
>   with /usr/bin as a symlink to /bin, etc. (this is the reverse of
>   merged-/usr, and was historically used in the hurd-i386 port)
>
> - a "symlink farm" in each of /bin, /sbin, /lib, /libQUAL with individual
>   symbolic links such as /bin/bash -> /usr/bin/bash for only those files that
>   historically had their canonical logical location on the root filesystem
>
> - a "symlink farm" in each of /bin, /sbin, /lib, /libQUAL with individual
>   symbolic links such as /bin/env -> /usr/bin/env for all files in the
>   affected directories, regardless of whether they historically had
>   their canonical logical location on the root filesystem
>
> [1]: 
> https://www.debian.org/doc/packaging-manuals/fhs/fhs-3.0.html#libltqualgtAlternateFormatEssential
>
> Upgrade path from Debian 11 to Debian 12
> 
>
> The technical committee resolved in #978636 [2] that Debian 12 'bookworm'
> should only support the merged-/usr layout. This resolution describes
> the implications of that decision in more detail.
>
> Debian installations have traditionally had a straightforward upgrade
> path between consecutive releases, and the technical committee expects
> maintainers to continue this. In the case of #978636, the 

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

[Elana Hashman]

On Wed, Oct 13, 2021 at 08:13:08PM +0100, Simon McVittie wrote:
> I'm calling for votes on the following resolution as formal advice from
> the Technical Committee (Constitution §6.1.5). There are no non-accepted
> amendments, so the options to vote on are "yes" or "further discussion".

I vote (belatedly, for the record):

yes > FD

- e

> 
>  begin text to be voted on 
> 
> Summary
> ===
> 
> There are currently Debian 11 installations with both the merged-/usr and
> non-merged-/usr filesystem layouts. All of these installations should
> successfully upgrade via normal upgrade paths to a merged-/usr Debian 12.
> Only after the release of Debian 12 can packages assume that all
> installations will be merged-/usr.
> 
> Main points:
> 
> - We have recommended merged-/usr for Debian 12.
> - Moving individual files is not merged-/usr.
> - "Symlink farms" are not merged-/usr.
> - Upgrading a non-merged-/usr system to Debian 12 needs to work.
> - Upgrading a merged-/usr system to Debian 12 needs to work.
> - Packages cannot assume all systems are merged-/usr until the Debian 13
>   development cycle begins.
> - Upgrading via apt in the usual way should work.
> - Testing and QA systems should be able to avoid this transition, but if
>   they do, they cannot be upgraded beyond Debian 12.
> - A package building incorrectly on a non-merged-/usr system is a bug.
> - A package building incorrectly on a merged-/usr system is a bug.
> - Please stop moving individual packages' files from the root filesystem
>   into /usr, at least for now.
> 
> Definitions and current status
> ==
> 
> libQUAL refers to the directories described in FHS 3.0 section 3.10 [1],
> such as lib64 on the amd64 architecture.
> 
> Merged /usr is the filesystem layout in which /bin, /sbin, /lib and each
> /libQUAL that exists are symbolic links to the corresponding directories
> below /usr. This results in aliasing between /bin and /usr/bin, and
> so on.
> 
> In the merged-/usr layout, files whose canonical logical location is
> in one of the affected directories on the root filesystem, such as
> /bin/bash, /sbin/fsck and /lib/ld-linux.so.2, are physically located at
> the corresponding path below /usr, such as /usr/bin/bash. Each file in
> one of the affected directories is accessible via two paths: its canonical
> logical location (such as /bin/bash or /usr/bin/env), and the other path
> implied by the aliasing (such as /usr/bin/bash or /bin/env).
> 
> There are two supported categories of Debian 11 installation, which are
> currently considered equally-supported:
> 
> - Merged-/usr installations. These were installed with debian-installer
>   from Debian 10 or later, or installed with debootstrap --merged-usr,
>   or converted from the non-merged-/usr layout by installing the usrmerge
>   package, or installed or converted by any similar procedure. They have
>   the merged-/usr layout.
> 
> - Non-merged-/usr installations. These were installed with debian-installer
>   from Debian 9 or earlier and subsequently upgraded without converting
>   to merged-/usr, or installed with debootstrap --no-merged-usr, or
>   converted from the merged-/usr layout with dpkg's "dpkg-fsys-usrunmess"
>   utility or any similar procedure. They have the traditional,
>   non-merged-/usr layout in which /bin/bash and /usr/bin/env have exactly
>   those physical paths, and /usr/bin/bash and /bin/env do not exist.
> 
> Merged-/usr is not the only filesystem layout that has been proposed for
> unifying the root filesystem with /usr. For avoidance of doubt, we do not
> consider other filesystem layouts to be implementations of merged-/usr.
> In particular, we do not consider these to be implementations of merged-/usr:
> 
> - all affected files physically located in /bin, /sbin, /lib and /libQUAL,
>   with /usr/bin as a symlink to /bin, etc. (this is the reverse of
>   merged-/usr, and was historically used in the hurd-i386 port)
> 
> - a "symlink farm" in each of /bin, /sbin, /lib, /libQUAL with individual
>   symbolic links such as /bin/bash -> /usr/bin/bash for only those files that
>   historically had their canonical logical location on the root filesystem
> 
> - a "symlink farm" in each of /bin, /sbin, /lib, /libQUAL with individual
>   symbolic links such as /bin/env -> /usr/bin/env for all files in the
>   affected directories, regardless of whether they historically had
>   their canonical logical location on the root filesystem
> 
> [1]: 
> https://www.debian.org/doc/packaging-manuals/fhs/fhs-3.0.html#libltqualgtAlternateFormatEssential
> 
> Upgrade path from Debian 11 to Debian 12
> 
> 
> The technical committee resolved in #978636 [2] that Debian 12 'bookworm'
> should only support the merged-/usr layout. This resolution describes
> the implications of that decision in more detail.
> 
> Debian installations have traditionally had a straightforward upgrade
> path between 

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

[Christoph Berg]

Re: Simon McVittie
> I'm calling for votes on the following resolution as formal advice from
> the Technical Committee (Constitution §6.1.5). There are no non-accepted
> amendments, so the options to vote on are "yes" or "further discussion".

I vote yes > further discussion.

>  begin text to be voted on 
> 
> Summary
> ===
> 
> There are currently Debian 11 installations with both the merged-/usr and
> non-merged-/usr filesystem layouts. All of these installations should
> successfully upgrade via normal upgrade paths to a merged-/usr Debian 12.
> Only after the release of Debian 12 can packages assume that all
> installations will be merged-/usr.
> 
> Main points:
> 
> - We have recommended merged-/usr for Debian 12.
> - Moving individual files is not merged-/usr.
> - "Symlink farms" are not merged-/usr.
> - Upgrading a non-merged-/usr system to Debian 12 needs to work.
> - Upgrading a merged-/usr system to Debian 12 needs to work.
> - Packages cannot assume all systems are merged-/usr until the Debian 13
>   development cycle begins.
> - Upgrading via apt in the usual way should work.
> - Testing and QA systems should be able to avoid this transition, but if
>   they do, they cannot be upgraded beyond Debian 12.
> - A package building incorrectly on a non-merged-/usr system is a bug.
> - A package building incorrectly on a merged-/usr system is a bug.
> - Please stop moving individual packages' files from the root filesystem
>   into /usr, at least for now.
> 
> Definitions and current status
> ==
> 
> libQUAL refers to the directories described in FHS 3.0 section 3.10 [1],
> such as lib64 on the amd64 architecture.
> 
> Merged /usr is the filesystem layout in which /bin, /sbin, /lib and each
> /libQUAL that exists are symbolic links to the corresponding directories
> below /usr. This results in aliasing between /bin and /usr/bin, and
> so on.
> 
> In the merged-/usr layout, files whose canonical logical location is
> in one of the affected directories on the root filesystem, such as
> /bin/bash, /sbin/fsck and /lib/ld-linux.so.2, are physically located at
> the corresponding path below /usr, such as /usr/bin/bash. Each file in
> one of the affected directories is accessible via two paths: its canonical
> logical location (such as /bin/bash or /usr/bin/env), and the other path
> implied by the aliasing (such as /usr/bin/bash or /bin/env).
> 
> There are two supported categories of Debian 11 installation, which are
> currently considered equally-supported:
> 
> - Merged-/usr installations. These were installed with debian-installer
>   from Debian 10 or later, or installed with debootstrap --merged-usr,
>   or converted from the non-merged-/usr layout by installing the usrmerge
>   package, or installed or converted by any similar procedure. They have
>   the merged-/usr layout.
> 
> - Non-merged-/usr installations. These were installed with debian-installer
>   from Debian 9 or earlier and subsequently upgraded without converting
>   to merged-/usr, or installed with debootstrap --no-merged-usr, or
>   converted from the merged-/usr layout with dpkg's "dpkg-fsys-usrunmess"
>   utility or any similar procedure. They have the traditional,
>   non-merged-/usr layout in which /bin/bash and /usr/bin/env have exactly
>   those physical paths, and /usr/bin/bash and /bin/env do not exist.
> 
> Merged-/usr is not the only filesystem layout that has been proposed for
> unifying the root filesystem with /usr. For avoidance of doubt, we do not
> consider other filesystem layouts to be implementations of merged-/usr.
> In particular, we do not consider these to be implementations of merged-/usr:
> 
> - all affected files physically located in /bin, /sbin, /lib and /libQUAL,
>   with /usr/bin as a symlink to /bin, etc. (this is the reverse of
>   merged-/usr, and was historically used in the hurd-i386 port)
> 
> - a "symlink farm" in each of /bin, /sbin, /lib, /libQUAL with individual
>   symbolic links such as /bin/bash -> /usr/bin/bash for only those files that
>   historically had their canonical logical location on the root filesystem
> 
> - a "symlink farm" in each of /bin, /sbin, /lib, /libQUAL with individual
>   symbolic links such as /bin/env -> /usr/bin/env for all files in the
>   affected directories, regardless of whether they historically had
>   their canonical logical location on the root filesystem
> 
> [1]: 
> https://www.debian.org/doc/packaging-manuals/fhs/fhs-3.0.html#libltqualgtAlternateFormatEssential
> 
> Upgrade path from Debian 11 to Debian 12
> 
> 
> The technical committee resolved in #978636 [2] that Debian 12 'bookworm'
> should only support the merged-/usr layout. This resolution describes
> the implications of that decision in more detail.
> 
> Debian installations have traditionally had a straightforward upgrade
> path between consecutive releases, and the technical committee expects
> maintainers to 

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

[Margarita Manterola]

> I'm calling for votes on the following resolution as formal advice from
> the Technical Committee (Constitution §6.1.5). There are no non-accepted
> amendments, so the options to vote on are "yes" or "further discussion".

My vote on the text quoted below:
  yes > further discussion

> 
>  begin text to be voted on 
> 
> Summary
> ===
> 
> There are currently Debian 11 installations with both the merged-/usr and
> non-merged-/usr filesystem layouts. All of these installations should
> successfully upgrade via normal upgrade paths to a merged-/usr Debian 12.
> Only after the release of Debian 12 can packages assume that all
> installations will be merged-/usr.
> 
> Main points:
> 
> - We have recommended merged-/usr for Debian 12.
> - Moving individual files is not merged-/usr.
> - "Symlink farms" are not merged-/usr.
> - Upgrading a non-merged-/usr system to Debian 12 needs to work.
> - Upgrading a merged-/usr system to Debian 12 needs to work.
> - Packages cannot assume all systems are merged-/usr until the Debian 13
>   development cycle begins.
> - Upgrading via apt in the usual way should work.
> - Testing and QA systems should be able to avoid this transition, but if
>   they do, they cannot be upgraded beyond Debian 12.
> - A package building incorrectly on a non-merged-/usr system is a bug.
> - A package building incorrectly on a merged-/usr system is a bug.
> - Please stop moving individual packages' files from the root filesystem
>   into /usr, at least for now.
> 
> Definitions and current status
> ==
> 
> libQUAL refers to the directories described in FHS 3.0 section 3.10 [1],
> such as lib64 on the amd64 architecture.
> 
> Merged /usr is the filesystem layout in which /bin, /sbin, /lib and each
> /libQUAL that exists are symbolic links to the corresponding directories
> below /usr. This results in aliasing between /bin and /usr/bin, and
> so on.
> 
> In the merged-/usr layout, files whose canonical logical location is
> in one of the affected directories on the root filesystem, such as
> /bin/bash, /sbin/fsck and /lib/ld-linux.so.2, are physically located at
> the corresponding path below /usr, such as /usr/bin/bash. Each file in
> one of the affected directories is accessible via two paths: its canonical
> logical location (such as /bin/bash or /usr/bin/env), and the other path
> implied by the aliasing (such as /usr/bin/bash or /bin/env).
> 
> There are two supported categories of Debian 11 installation, which are
> currently considered equally-supported:
> 
> - Merged-/usr installations. These were installed with debian-installer
>   from Debian 10 or later, or installed with debootstrap --merged-usr,
>   or converted from the non-merged-/usr layout by installing the usrmerge
>   package, or installed or converted by any similar procedure. They have
>   the merged-/usr layout.
> 
> - Non-merged-/usr installations. These were installed with debian-installer
>   from Debian 9 or earlier and subsequently upgraded without converting
>   to merged-/usr, or installed with debootstrap --no-merged-usr, or
>   converted from the merged-/usr layout with dpkg's "dpkg-fsys-usrunmess"
>   utility or any similar procedure. They have the traditional,
>   non-merged-/usr layout in which /bin/bash and /usr/bin/env have exactly
>   those physical paths, and /usr/bin/bash and /bin/env do not exist.
> 
> Merged-/usr is not the only filesystem layout that has been proposed for
> unifying the root filesystem with /usr. For avoidance of doubt, we do not
> consider other filesystem layouts to be implementations of merged-/usr.
> In particular, we do not consider these to be implementations of merged-/usr:
> 
> - all affected files physically located in /bin, /sbin, /lib and /libQUAL,
>   with /usr/bin as a symlink to /bin, etc. (this is the reverse of
>   merged-/usr, and was historically used in the hurd-i386 port)
> 
> - a "symlink farm" in each of /bin, /sbin, /lib, /libQUAL with individual
>   symbolic links such as /bin/bash -> /usr/bin/bash for only those files that
>   historically had their canonical logical location on the root filesystem
> 
> - a "symlink farm" in each of /bin, /sbin, /lib, /libQUAL with individual
>   symbolic links such as /bin/env -> /usr/bin/env for all files in the
>   affected directories, regardless of whether they historically had
>   their canonical logical location on the root filesystem
> 
> [1]: 
> https://www.debian.org/doc/packaging-manuals/fhs/fhs-3.0.html#libltqualgtAlternateFormatEssential
> 
> Upgrade path from Debian 11 to Debian 12
> 
> 
> The technical committee resolved in #978636 [2] that Debian 12 'bookworm'
> should only support the merged-/usr layout. This resolution describes
> the implications of that decision in more detail.
> 
> Debian installations have traditionally had a straightforward upgrade
> path between consecutive releases, and the technical committee expects
> 

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

[Sean Whitton]

Hello,

On Wed 13 Oct 2021 at 08:13PM +01, Simon McVittie wrote:

> I'm calling for votes on the following resolution as formal advice from
> the Technical Committee (Constitution §6.1.5). There are no non-accepted
> amendments, so the options to vote on are "yes" or "further discussion".

I vote

yes > further discussion

>  begin text to be voted on 
>
> Summary
> ===
>
> There are currently Debian 11 installations with both the merged-/usr and
> non-merged-/usr filesystem layouts. All of these installations should
> successfully upgrade via normal upgrade paths to a merged-/usr Debian 12.
> Only after the release of Debian 12 can packages assume that all
> installations will be merged-/usr.
>
> Main points:
>
> - We have recommended merged-/usr for Debian 12.
> - Moving individual files is not merged-/usr.
> - "Symlink farms" are not merged-/usr.
> - Upgrading a non-merged-/usr system to Debian 12 needs to work.
> - Upgrading a merged-/usr system to Debian 12 needs to work.
> - Packages cannot assume all systems are merged-/usr until the Debian 13
>   development cycle begins.
> - Upgrading via apt in the usual way should work.
> - Testing and QA systems should be able to avoid this transition, but if
>   they do, they cannot be upgraded beyond Debian 12.
> - A package building incorrectly on a non-merged-/usr system is a bug.
> - A package building incorrectly on a merged-/usr system is a bug.
> - Please stop moving individual packages' files from the root filesystem
>   into /usr, at least for now.
>
> Definitions and current status
> ==
>
> libQUAL refers to the directories described in FHS 3.0 section 3.10 [1],
> such as lib64 on the amd64 architecture.
>
> Merged /usr is the filesystem layout in which /bin, /sbin, /lib and each
> /libQUAL that exists are symbolic links to the corresponding directories
> below /usr. This results in aliasing between /bin and /usr/bin, and
> so on.
>
> In the merged-/usr layout, files whose canonical logical location is
> in one of the affected directories on the root filesystem, such as
> /bin/bash, /sbin/fsck and /lib/ld-linux.so.2, are physically located at
> the corresponding path below /usr, such as /usr/bin/bash. Each file in
> one of the affected directories is accessible via two paths: its canonical
> logical location (such as /bin/bash or /usr/bin/env), and the other path
> implied by the aliasing (such as /usr/bin/bash or /bin/env).
>
> There are two supported categories of Debian 11 installation, which are
> currently considered equally-supported:
>
> - Merged-/usr installations. These were installed with debian-installer
>   from Debian 10 or later, or installed with debootstrap --merged-usr,
>   or converted from the non-merged-/usr layout by installing the usrmerge
>   package, or installed or converted by any similar procedure. They have
>   the merged-/usr layout.
>
> - Non-merged-/usr installations. These were installed with debian-installer
>   from Debian 9 or earlier and subsequently upgraded without converting
>   to merged-/usr, or installed with debootstrap --no-merged-usr, or
>   converted from the merged-/usr layout with dpkg's "dpkg-fsys-usrunmess"
>   utility or any similar procedure. They have the traditional,
>   non-merged-/usr layout in which /bin/bash and /usr/bin/env have exactly
>   those physical paths, and /usr/bin/bash and /bin/env do not exist.
>
> Merged-/usr is not the only filesystem layout that has been proposed for
> unifying the root filesystem with /usr. For avoidance of doubt, we do not
> consider other filesystem layouts to be implementations of merged-/usr.
> In particular, we do not consider these to be implementations of merged-/usr:
>
> - all affected files physically located in /bin, /sbin, /lib and /libQUAL,
>   with /usr/bin as a symlink to /bin, etc. (this is the reverse of
>   merged-/usr, and was historically used in the hurd-i386 port)
>
> - a "symlink farm" in each of /bin, /sbin, /lib, /libQUAL with individual
>   symbolic links such as /bin/bash -> /usr/bin/bash for only those files that
>   historically had their canonical logical location on the root filesystem
>
> - a "symlink farm" in each of /bin, /sbin, /lib, /libQUAL with individual
>   symbolic links such as /bin/env -> /usr/bin/env for all files in the
>   affected directories, regardless of whether they historically had
>   their canonical logical location on the root filesystem
>
> [1]: 
> https://www.debian.org/doc/packaging-manuals/fhs/fhs-3.0.html#libltqualgtAlternateFormatEssential
>
> Upgrade path from Debian 11 to Debian 12
> 
>
> The technical committee resolved in #978636 [2] that Debian 12 'bookworm'
> should only support the merged-/usr layout. This resolution describes
> the implications of that decision in more detail.
>
> Debian installations have traditionally had a straightforward upgrade
> path between consecutive releases, and the technical 

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

[Gunnar Wolf]

Simon McVittie dijo [Wed, Oct 13, 2021 at 08:13:08PM +0100]:
> I'm calling for votes on the following resolution as formal advice from
> the Technical Committee (Constitution §6.1.5). There are no non-accepted
> amendments, so the options to vote on are "yes" or "further discussion".

My vote on the text quoted below is:

yes > further discussion

>  begin text to be voted on 
> 
> Summary
> ===
> 
> There are currently Debian 11 installations with both the merged-/usr and
> non-merged-/usr filesystem layouts. All of these installations should
> successfully upgrade via normal upgrade paths to a merged-/usr Debian 12.
> Only after the release of Debian 12 can packages assume that all
> installations will be merged-/usr.
> 
> Main points:
> 
> - We have recommended merged-/usr for Debian 12.
> - Moving individual files is not merged-/usr.
> - "Symlink farms" are not merged-/usr.
> - Upgrading a non-merged-/usr system to Debian 12 needs to work.
> - Upgrading a merged-/usr system to Debian 12 needs to work.
> - Packages cannot assume all systems are merged-/usr until the Debian 13
>   development cycle begins.
> - Upgrading via apt in the usual way should work.
> - Testing and QA systems should be able to avoid this transition, but if
>   they do, they cannot be upgraded beyond Debian 12.
> - A package building incorrectly on a non-merged-/usr system is a bug.
> - A package building incorrectly on a merged-/usr system is a bug.
> - Please stop moving individual packages' files from the root filesystem
>   into /usr, at least for now.
> 
> Definitions and current status
> ==
> 
> libQUAL refers to the directories described in FHS 3.0 section 3.10 [1],
> such as lib64 on the amd64 architecture.
> 
> Merged /usr is the filesystem layout in which /bin, /sbin, /lib and each
> /libQUAL that exists are symbolic links to the corresponding directories
> below /usr. This results in aliasing between /bin and /usr/bin, and
> so on.
> 
> In the merged-/usr layout, files whose canonical logical location is
> in one of the affected directories on the root filesystem, such as
> /bin/bash, /sbin/fsck and /lib/ld-linux.so.2, are physically located at
> the corresponding path below /usr, such as /usr/bin/bash. Each file in
> one of the affected directories is accessible via two paths: its canonical
> logical location (such as /bin/bash or /usr/bin/env), and the other path
> implied by the aliasing (such as /usr/bin/bash or /bin/env).
> 
> There are two supported categories of Debian 11 installation, which are
> currently considered equally-supported:
> 
> - Merged-/usr installations. These were installed with debian-installer
>   from Debian 10 or later, or installed with debootstrap --merged-usr,
>   or converted from the non-merged-/usr layout by installing the usrmerge
>   package, or installed or converted by any similar procedure. They have
>   the merged-/usr layout.
> 
> - Non-merged-/usr installations. These were installed with debian-installer
>   from Debian 9 or earlier and subsequently upgraded without converting
>   to merged-/usr, or installed with debootstrap --no-merged-usr, or
>   converted from the merged-/usr layout with dpkg's "dpkg-fsys-usrunmess"
>   utility or any similar procedure. They have the traditional,
>   non-merged-/usr layout in which /bin/bash and /usr/bin/env have exactly
>   those physical paths, and /usr/bin/bash and /bin/env do not exist.
> 
> Merged-/usr is not the only filesystem layout that has been proposed for
> unifying the root filesystem with /usr. For avoidance of doubt, we do not
> consider other filesystem layouts to be implementations of merged-/usr.
> In particular, we do not consider these to be implementations of merged-/usr:
> 
> - all affected files physically located in /bin, /sbin, /lib and /libQUAL,
>   with /usr/bin as a symlink to /bin, etc. (this is the reverse of
>   merged-/usr, and was historically used in the hurd-i386 port)
> 
> - a "symlink farm" in each of /bin, /sbin, /lib, /libQUAL with individual
>   symbolic links such as /bin/bash -> /usr/bin/bash for only those files that
>   historically had their canonical logical location on the root filesystem
> 
> - a "symlink farm" in each of /bin, /sbin, /lib, /libQUAL with individual
>   symbolic links such as /bin/env -> /usr/bin/env for all files in the
>   affected directories, regardless of whether they historically had
>   their canonical logical location on the root filesystem
> 
> [1]: 
> https://www.debian.org/doc/packaging-manuals/fhs/fhs-3.0.html#libltqualgtAlternateFormatEssential
> 
> Upgrade path from Debian 11 to Debian 12
> 
> 
> The technical committee resolved in #978636 [2] that Debian 12 'bookworm'
> should only support the merged-/usr layout. This resolution describes
> the implications of that decision in more detail.
> 
> Debian installations have traditionally had a straightforward upgrade
> path between 

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

[Niko Tyni]

On Wed, Oct 13, 2021 at 08:13:08PM +0100, Simon McVittie wrote:
> I'm calling for votes on the following resolution as formal advice from
> the Technical Committee (Constitution §6.1.5). There are no non-accepted
> amendments, so the options to vote on are "yes" or "further discussion".

I vote: "yes" > "further discussion".

>  begin text to be voted on 
> 
> Summary
> ===
> 
> There are currently Debian 11 installations with both the merged-/usr and
> non-merged-/usr filesystem layouts. All of these installations should
> successfully upgrade via normal upgrade paths to a merged-/usr Debian 12.
> Only after the release of Debian 12 can packages assume that all
> installations will be merged-/usr.
> 
> Main points:
> 
> - We have recommended merged-/usr for Debian 12.
> - Moving individual files is not merged-/usr.
> - "Symlink farms" are not merged-/usr.
> - Upgrading a non-merged-/usr system to Debian 12 needs to work.
> - Upgrading a merged-/usr system to Debian 12 needs to work.
> - Packages cannot assume all systems are merged-/usr until the Debian 13
>   development cycle begins.
> - Upgrading via apt in the usual way should work.
> - Testing and QA systems should be able to avoid this transition, but if
>   they do, they cannot be upgraded beyond Debian 12.
> - A package building incorrectly on a non-merged-/usr system is a bug.
> - A package building incorrectly on a merged-/usr system is a bug.
> - Please stop moving individual packages' files from the root filesystem
>   into /usr, at least for now.
> 
> Definitions and current status
> ==
> 
> libQUAL refers to the directories described in FHS 3.0 section 3.10 [1],
> such as lib64 on the amd64 architecture.
> 
> Merged /usr is the filesystem layout in which /bin, /sbin, /lib and each
> /libQUAL that exists are symbolic links to the corresponding directories
> below /usr. This results in aliasing between /bin and /usr/bin, and
> so on.
> 
> In the merged-/usr layout, files whose canonical logical location is
> in one of the affected directories on the root filesystem, such as
> /bin/bash, /sbin/fsck and /lib/ld-linux.so.2, are physically located at
> the corresponding path below /usr, such as /usr/bin/bash. Each file in
> one of the affected directories is accessible via two paths: its canonical
> logical location (such as /bin/bash or /usr/bin/env), and the other path
> implied by the aliasing (such as /usr/bin/bash or /bin/env).
> 
> There are two supported categories of Debian 11 installation, which are
> currently considered equally-supported:
> 
> - Merged-/usr installations. These were installed with debian-installer
>   from Debian 10 or later, or installed with debootstrap --merged-usr,
>   or converted from the non-merged-/usr layout by installing the usrmerge
>   package, or installed or converted by any similar procedure. They have
>   the merged-/usr layout.
> 
> - Non-merged-/usr installations. These were installed with debian-installer
>   from Debian 9 or earlier and subsequently upgraded without converting
>   to merged-/usr, or installed with debootstrap --no-merged-usr, or
>   converted from the merged-/usr layout with dpkg's "dpkg-fsys-usrunmess"
>   utility or any similar procedure. They have the traditional,
>   non-merged-/usr layout in which /bin/bash and /usr/bin/env have exactly
>   those physical paths, and /usr/bin/bash and /bin/env do not exist.
> 
> Merged-/usr is not the only filesystem layout that has been proposed for
> unifying the root filesystem with /usr. For avoidance of doubt, we do not
> consider other filesystem layouts to be implementations of merged-/usr.
> In particular, we do not consider these to be implementations of merged-/usr:
> 
> - all affected files physically located in /bin, /sbin, /lib and /libQUAL,
>   with /usr/bin as a symlink to /bin, etc. (this is the reverse of
>   merged-/usr, and was historically used in the hurd-i386 port)
> 
> - a "symlink farm" in each of /bin, /sbin, /lib, /libQUAL with individual
>   symbolic links such as /bin/bash -> /usr/bin/bash for only those files that
>   historically had their canonical logical location on the root filesystem
> 
> - a "symlink farm" in each of /bin, /sbin, /lib, /libQUAL with individual
>   symbolic links such as /bin/env -> /usr/bin/env for all files in the
>   affected directories, regardless of whether they historically had
>   their canonical logical location on the root filesystem
> 
> [1]: 
> https://www.debian.org/doc/packaging-manuals/fhs/fhs-3.0.html#libltqualgtAlternateFormatEssential
> 
> Upgrade path from Debian 11 to Debian 12
> 
> 
> The technical committee resolved in #978636 [2] that Debian 12 'bookworm'
> should only support the merged-/usr layout. This resolution describes
> the implications of that decision in more detail.
> 
> Debian installations have traditionally had a straightforward upgrade
> path between consecutive releases, and 

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

[Simon McVittie]

On Wed, 13 Oct 2021 at 20:13:08 +0100, Simon McVittie wrote:
> I'm calling for votes on the following resolution as formal advice from
> the Technical Committee (Constitution §6.1.5). There are no non-accepted
> amendments, so the options to vote on are "yes" or "further discussion".

I vote yes > further discussion.

>  begin text to be voted on 
> 
> Summary
> ===
> 
> There are currently Debian 11 installations with both the merged-/usr and
> non-merged-/usr filesystem layouts. All of these installations should
> successfully upgrade via normal upgrade paths to a merged-/usr Debian 12.
> Only after the release of Debian 12 can packages assume that all
> installations will be merged-/usr.
> 
> Main points:
> 
> - We have recommended merged-/usr for Debian 12.
> - Moving individual files is not merged-/usr.
> - "Symlink farms" are not merged-/usr.
> - Upgrading a non-merged-/usr system to Debian 12 needs to work.
> - Upgrading a merged-/usr system to Debian 12 needs to work.
> - Packages cannot assume all systems are merged-/usr until the Debian 13
>   development cycle begins.
> - Upgrading via apt in the usual way should work.
> - Testing and QA systems should be able to avoid this transition, but if
>   they do, they cannot be upgraded beyond Debian 12.
> - A package building incorrectly on a non-merged-/usr system is a bug.
> - A package building incorrectly on a merged-/usr system is a bug.
> - Please stop moving individual packages' files from the root filesystem
>   into /usr, at least for now.
> 
> Definitions and current status
> ==
> 
> libQUAL refers to the directories described in FHS 3.0 section 3.10 [1],
> such as lib64 on the amd64 architecture.
> 
> Merged /usr is the filesystem layout in which /bin, /sbin, /lib and each
> /libQUAL that exists are symbolic links to the corresponding directories
> below /usr. This results in aliasing between /bin and /usr/bin, and
> so on.
> 
> In the merged-/usr layout, files whose canonical logical location is
> in one of the affected directories on the root filesystem, such as
> /bin/bash, /sbin/fsck and /lib/ld-linux.so.2, are physically located at
> the corresponding path below /usr, such as /usr/bin/bash. Each file in
> one of the affected directories is accessible via two paths: its canonical
> logical location (such as /bin/bash or /usr/bin/env), and the other path
> implied by the aliasing (such as /usr/bin/bash or /bin/env).
> 
> There are two supported categories of Debian 11 installation, which are
> currently considered equally-supported:
> 
> - Merged-/usr installations. These were installed with debian-installer
>   from Debian 10 or later, or installed with debootstrap --merged-usr,
>   or converted from the non-merged-/usr layout by installing the usrmerge
>   package, or installed or converted by any similar procedure. They have
>   the merged-/usr layout.
> 
> - Non-merged-/usr installations. These were installed with debian-installer
>   from Debian 9 or earlier and subsequently upgraded without converting
>   to merged-/usr, or installed with debootstrap --no-merged-usr, or
>   converted from the merged-/usr layout with dpkg's "dpkg-fsys-usrunmess"
>   utility or any similar procedure. They have the traditional,
>   non-merged-/usr layout in which /bin/bash and /usr/bin/env have exactly
>   those physical paths, and /usr/bin/bash and /bin/env do not exist.
> 
> Merged-/usr is not the only filesystem layout that has been proposed for
> unifying the root filesystem with /usr. For avoidance of doubt, we do not
> consider other filesystem layouts to be implementations of merged-/usr.
> In particular, we do not consider these to be implementations of merged-/usr:
> 
> - all affected files physically located in /bin, /sbin, /lib and /libQUAL,
>   with /usr/bin as a symlink to /bin, etc. (this is the reverse of
>   merged-/usr, and was historically used in the hurd-i386 port)
> 
> - a "symlink farm" in each of /bin, /sbin, /lib, /libQUAL with individual
>   symbolic links such as /bin/bash -> /usr/bin/bash for only those files that
>   historically had their canonical logical location on the root filesystem
> 
> - a "symlink farm" in each of /bin, /sbin, /lib, /libQUAL with individual
>   symbolic links such as /bin/env -> /usr/bin/env for all files in the
>   affected directories, regardless of whether they historically had
>   their canonical logical location on the root filesystem
> 
> [1]: 
> https://www.debian.org/doc/packaging-manuals/fhs/fhs-3.0.html#libltqualgtAlternateFormatEssential
> 
> Upgrade path from Debian 11 to Debian 12
> 
> 
> The technical committee resolved in #978636 [2] that Debian 12 'bookworm'
> should only support the merged-/usr layout. This resolution describes
> the implications of that decision in more detail.
> 
> Debian installations have traditionally had a straightforward upgrade
> path between consecutive releases, and the 

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

[Simon McVittie]

I'm calling for votes on the following resolution as formal advice from
the Technical Committee (Constitution §6.1.5). There are no non-accepted
amendments, so the options to vote on are "yes" or "further discussion".

 begin text to be voted on 

Summary
===

There are currently Debian 11 installations with both the merged-/usr and
non-merged-/usr filesystem layouts. All of these installations should
successfully upgrade via normal upgrade paths to a merged-/usr Debian 12.
Only after the release of Debian 12 can packages assume that all
installations will be merged-/usr.

Main points:

- We have recommended merged-/usr for Debian 12.
- Moving individual files is not merged-/usr.
- "Symlink farms" are not merged-/usr.
- Upgrading a non-merged-/usr system to Debian 12 needs to work.
- Upgrading a merged-/usr system to Debian 12 needs to work.
- Packages cannot assume all systems are merged-/usr until the Debian 13
  development cycle begins.
- Upgrading via apt in the usual way should work.
- Testing and QA systems should be able to avoid this transition, but if
  they do, they cannot be upgraded beyond Debian 12.
- A package building incorrectly on a non-merged-/usr system is a bug.
- A package building incorrectly on a merged-/usr system is a bug.
- Please stop moving individual packages' files from the root filesystem
  into /usr, at least for now.

Definitions and current status
==

libQUAL refers to the directories described in FHS 3.0 section 3.10 [1],
such as lib64 on the amd64 architecture.

Merged /usr is the filesystem layout in which /bin, /sbin, /lib and each
/libQUAL that exists are symbolic links to the corresponding directories
below /usr. This results in aliasing between /bin and /usr/bin, and
so on.

In the merged-/usr layout, files whose canonical logical location is
in one of the affected directories on the root filesystem, such as
/bin/bash, /sbin/fsck and /lib/ld-linux.so.2, are physically located at
the corresponding path below /usr, such as /usr/bin/bash. Each file in
one of the affected directories is accessible via two paths: its canonical
logical location (such as /bin/bash or /usr/bin/env), and the other path
implied by the aliasing (such as /usr/bin/bash or /bin/env).

There are two supported categories of Debian 11 installation, which are
currently considered equally-supported:

- Merged-/usr installations. These were installed with debian-installer
  from Debian 10 or later, or installed with debootstrap --merged-usr,
  or converted from the non-merged-/usr layout by installing the usrmerge
  package, or installed or converted by any similar procedure. They have
  the merged-/usr layout.

- Non-merged-/usr installations. These were installed with debian-installer
  from Debian 9 or earlier and subsequently upgraded without converting
  to merged-/usr, or installed with debootstrap --no-merged-usr, or
  converted from the merged-/usr layout with dpkg's "dpkg-fsys-usrunmess"
  utility or any similar procedure. They have the traditional,
  non-merged-/usr layout in which /bin/bash and /usr/bin/env have exactly
  those physical paths, and /usr/bin/bash and /bin/env do not exist.

Merged-/usr is not the only filesystem layout that has been proposed for
unifying the root filesystem with /usr. For avoidance of doubt, we do not
consider other filesystem layouts to be implementations of merged-/usr.
In particular, we do not consider these to be implementations of merged-/usr:

- all affected files physically located in /bin, /sbin, /lib and /libQUAL,
  with /usr/bin as a symlink to /bin, etc. (this is the reverse of
  merged-/usr, and was historically used in the hurd-i386 port)

- a "symlink farm" in each of /bin, /sbin, /lib, /libQUAL with individual
  symbolic links such as /bin/bash -> /usr/bin/bash for only those files that
  historically had their canonical logical location on the root filesystem

- a "symlink farm" in each of /bin, /sbin, /lib, /libQUAL with individual
  symbolic links such as /bin/env -> /usr/bin/env for all files in the
  affected directories, regardless of whether they historically had
  their canonical logical location on the root filesystem

[1]: 
https://www.debian.org/doc/packaging-manuals/fhs/fhs-3.0.html#libltqualgtAlternateFormatEssential

Upgrade path from Debian 11 to Debian 12


The technical committee resolved in #978636 [2] that Debian 12 'bookworm'
should only support the merged-/usr layout. This resolution describes
the implications of that decision in more detail.

Debian installations have traditionally had a straightforward upgrade
path between consecutive releases, and the technical committee expects
maintainers to continue this. In the case of #978636, the upgrades we
are interested in are:

- Upgrading from Debian 11 (stable release) to Debian 12 (stable release)

- Upgrading from Debian 11 (stable release) to testing/unstable during the
  development cycle 

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

[Sean Whitton]

Hello Simon,

On Tue 05 Oct 2021 at 07:48PM +01, Simon McVittie wrote:

> On Sun, 03 Oct 2021 at 16:52:15 -0700, Sean Whitton wrote:
>> On Mon 27 Sep 2021 at 10:59AM +01, Simon McVittie wrote:
>> > On Thu, 16 Sep 2021 at 15:35:11 -0700, Sean Whitton wrote:
>> >> (1) The reason for this, to put it a bit simplistically, is that we
>> >> don't require apt to perform the upgrade between stable releases in any
>> >> particular order, right?  Or are there other reasons distinct from this
>> >> one that I'm missing?  I think it would be good to state the thing about
>> >> apt (in better language than mine) in the text.
>> >
>> > I think that's the main reason. We have not traditionally mandated
>> > the use of a special upgrade tool like Ubuntu's do-release-upgrade(8),
>> > so the upgrade happens in whatever order apt chooses, which can vary
>> > between machines.
>> >
>> > Another reason why I think we want Debian 12 packages to be installable
>> > onto non-merged-/usr systems is that to be able to do our development work,
>> > they need to be installable onto testing/unstable systems, which (again)
>> > means that the upgrade order is undefined.
>>
>> Right, we're on the same page then, but would you agree with me that the
>> resolution should state this justification explicitly?
>
> I hope that
> 
> implements this to your satisfaction. If not, suggestions for better
> wording welcome - I would prefer not to be the only one writing this
> document!

Thanks, yes, this addresses my feedback.

I've pushed some wording tweaks.  Hope you don't mind me not filing a
MR -- seemed uncontroversial so thought I'd just push.

-- 
Sean Whitton


signature.asc
Description: PGP signature

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

[Niko Tyni]

On Wed, Sep 15, 2021 at 12:35:38PM +0100, Simon McVittie wrote:

> https://salsa.debian.org/debian/tech-ctte/-/blob/master/994388_merged_usr_advice/draft.md

Many thanks for your work, and sorry for not participating earlier.

I agree with you that it would be good to send advice out sooner
rather than later.

I also agree with pretty much all you're saying in the text.

In particular:

> Questions for the committee:
> 
> - §(Definitions and current status): Does everyone agree with my
>   characterization of where we are now?

Ack from me.

> - §(Upgrade path from Debian 11 to Debian 12): Does everyone agree
>   with what I've written here about the implications of #978636?

I think I can follow the logic, and I agree with it.

> - §(Upgrade path from Debian 11 to Debian 12): Is the last paragraph
>   "If a suitable transition mechanism is not available by the time the
>   Debian 12 freeze is reached..." necessary, or is it implicit that
>   *obviously* we won't demand that the project carries on with merged-/usr
>   if it turns out not to be possible?

I think it should be included.

> - §(Testing and QA): Do we want to recommend this?

It does feel a bit like micro-managing to me. But the reasoning
makes sense. I'm fine with recommending it.
 
> - §(Building packages): Does everyone agree with my interpretation of
>   what we agreed in #914897 and its implications? Do we need to make a
>   recommendation for the Debian 12 development cycle, or is it enough
>   to assume that the "middle" option that we resolved in #914897
>   continues to be our opinion?

I agree and I don't think we need a new recommendation.

> - §(Building packages): I almost wrote an extra paragraph about how
>   this class of bugs becomes a non-issue when merged-/usr is the only
>   supported layout - but actually it doesn't! If we consider building
>   packages while having /usr/local/bin/sed to be a supported thing you
>   can do, then we need to ensure that /usr/local/bin/sed doesn't get
>   hard-coded into the resulting package, and the steps you take to
>   make that happen are the same as the steps you take to fix this class
>   of bugs.

FWIW I think we've traditionally considered such /usr/local -related
issues as bugs in the build setup rather than in the packages.

> - §(Moratorium on moving files' logical locations into /usr):
>   I think we should stop moving files into /usr on an individual basis,
>   at least until the consequences are fully understood, and perhaps for
>   the whole Debian 12 release cycle (after which, assuming merged-/usr
>   goes as we have recommended, maintainers can swap their logical location
>   without needing a transitional mechanism any more). Implementing
>   merged-/usr as the only supported layout means that moving files into
>   /usr on an individual basis is mostly unnecessary, because it has no
>   practical effect any more.

Agreed on the moratorium, mainly because of the unnecessity and the
error-prone nature of the moves. Sam brought up concerns about the
Replaces failure mode mentioned in the text, that part might need
changing.

On Mon, Sep 27, 2021 at 10:59:37AM +0100, Simon McVittie wrote:

> I am a little concerned that usrmerge is doing more intrusive surgery on
> a running system than even what's normal for an apt/dpkg-based upgrade,
> so I would prefer not to rule out designs that defer this action to a
> later time.

I share this concern.

-- 
Niko

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

[Simon McVittie]

On Sun, 03 Oct 2021 at 16:52:15 -0700, Sean Whitton wrote:
> On Mon 27 Sep 2021 at 10:59AM +01, Simon McVittie wrote:
> > On Thu, 16 Sep 2021 at 15:35:11 -0700, Sean Whitton wrote:
> >> (1) The reason for this, to put it a bit simplistically, is that we
> >> don't require apt to perform the upgrade between stable releases in any
> >> particular order, right?  Or are there other reasons distinct from this
> >> one that I'm missing?  I think it would be good to state the thing about
> >> apt (in better language than mine) in the text.
> >
> > I think that's the main reason. We have not traditionally mandated
> > the use of a special upgrade tool like Ubuntu's do-release-upgrade(8),
> > so the upgrade happens in whatever order apt chooses, which can vary
> > between machines.
> >
> > Another reason why I think we want Debian 12 packages to be installable
> > onto non-merged-/usr systems is that to be able to do our development work,
> > they need to be installable onto testing/unstable systems, which (again)
> > means that the upgrade order is undefined.
> 
> Right, we're on the same page then, but would you agree with me that the
> resolution should state this justification explicitly?

I hope that

implements this to your satisfaction. If not, suggestions for better
wording welcome - I would prefer not to be the only one writing this
document!

> > [Reasoning in a previous mail] makes me reluctant to require a special
> > upgrade procedure if it is not strictly necessary.
> 
> This is persuasive.  What do you think about including it in the text?

This is also in
.

> > I'm honestly not sure which of these is "the" reason why I'm recommending
> > the conservative approach. Some combination of your second and third
> > points, I suppose?
> 
> Based on what you say above I think it's the second and third, indeed.
> If we add to the text the things I'm suggesting we add, I think this
> sort of query about our motivations will not arise in the minds of
> readers.

Does 
cover this? If not, please suggest something that would.

Thanks,
smcv

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

[Simon McVittie]

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

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

[Sean Whitton]

Hello,

On Mon 27 Sep 2021 at 10:59AM +01, Simon McVittie wrote:

> On Thu, 16 Sep 2021 at 15:35:11 -0700, Sean Whitton wrote:
>> You write:
>>
>> >> - Because Debian 11 installations with the non-merged-/usr layout already
>> >>   exist, all packages in Debian 12 should be installable onto a 
>> >> non-merged-/usr
>> >>   system along with their dependencies, and work correctly on the 
>> >> resulting
>> >>   system.
>>
>> (1) The reason for this, to put it a bit simplistically, is that we
>> don't require apt to perform the upgrade between stable releases in any
>> particular order, right?  Or are there other reasons distinct from this
>> one that I'm missing?  I think it would be good to state the thing about
>> apt (in better language than mine) in the text.
>
> I think that's the main reason. We have not traditionally mandated
> the use of a special upgrade tool like Ubuntu's do-release-upgrade(8),
> so the upgrade happens in whatever order apt chooses, which can vary
> between machines.
>
> Another reason why I think we want Debian 12 packages to be installable
> onto non-merged-/usr systems is that to be able to do our development work,
> they need to be installable onto testing/unstable systems, which (again)
> means that the upgrade order is undefined.

Right, we're on the same page then, but would you agree with me that the
resolution should state this justification explicitly?

> We also have best-effort support for partial upgrades, either
> oldstable -> stable or stable -> testing/unstable: upgrading only a
> subset of the available packages, plus their mandatory dependencies,
> but without also upgrading apparently-unrelated packages. This can
> only ever be partially supported, because it leads to a combinatorial
> explosion of possible partially-upgraded systems, and realistically we
> can never test them all; but I think it's best if we try to avoid
> knowingly making this worse.

I'd suggest we don't mention this as it's much more obscure and the
above is sufficient justification.

>> (2) Some people on -devel would seem to think that we can have smooth
>> upgrades from bullseye to bookworm without requiring support for
>> non-merged-/usr in every single package in bookworm, i.e., without
>> supporting non-merged-/usr for testing/unstable installations during the
>> current release cycle.
>
> Some people on -devel have argued that it would be OK to require use of
> a special upgrade tool analogous to Ubuntu's do-release-upgrade just this
> once, or that it would be OK to require a particular upgrade sequence. For
> example, we could ask users to install the usrmerge package first, and
> then upgrade; or if dpkg is modified to special-case the merged-/usr
> aliasing symlinks, then we might ask users to upgrade dpkg first, and
> then upgrade the rest of the system.
>
> I think there is considerable anecdotal evidence that many Debian users
> do not read the release notes, and if we ask them to carry out an upgrade
> procedure more complicated than
>
> $editor /etc/apt/sources.list && apt update && apt full-upgrade
>
> they will often ignore that request and still expect their upgrade to
> work (because in practice it often does, and we've been training users
> to expect that for years). That makes me reluctant to require a special
> upgrade procedure if it is not strictly necessary.

This is persuasive.  What do you think about including it in the text?
Specifically, mentioning that we are deciding, for the project, that
we are not going to do this using something like do-release-upgrade(8).

>> What smcv has been arguing for is the most conservative option.  But
>> which of the following is it the TC wants to say:
>>
>> - we are sure that this is the only way to ensure smooth upgrades, such
>>   that it pretty much follows from our previous decision on merged-/usr
>>
>> - we think there might be viable alternatives to requiring every package
>>   in bookworm to work on both layouts, but we aren't sure they are safe
>>   enough, so we're recommending a simple and conservative approach
>>
>> - we think that ensuring non-merged-/usr testing/unstable installations
>>   work during this release cycle is reason enough to take this highly
>>   conservative approach
>
> I'm honestly not sure which of these is "the" reason why I'm recommending
> the conservative approach. Some combination of your second and third
> points, I suppose?

Based on what you say above I think it's the second and third, indeed.
If we add to the text the things I'm suggesting we add, I think this
sort of query about our motivations will not arise in the minds of
readers.

Thanks!

-- 
Sean Whitton


signature.asc
Description: PGP signature

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

[Sam Hartman]

>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.



Simon, I've reviewed your draft, and with the exception of the above
text, it all seems consistent with my understanding of the technical
details.

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.
So I don't see how the above text is correct.


If I'm missing something, perhaps we could clarify the text, because I
suspect I have a better than average understanding of the issues.  If I
don't get it, others probably will misunderstand too.

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

[Simon McVittie]

On Wed, 15 Sep 2021 at 12:35:38 +0100, Simon McVittie wrote:
> https://salsa.debian.org/debian/tech-ctte/-/blob/master/994388_merged_usr_advice/draft.md

I have updated this draft to incorporate my edits from !3, and feedback
from bremner on IRC.

I'd like to keep this moving, because it's somewhat time-sensitive: people
are already taking action based on our earlier resolution, some of which is
not necessarily the action we would have wanted them to take.

On Wed, 15 Sep 2021 at 11:46:02 +0100, Simon McVittie wrote:
> Some questions that I think we need to answer explicitly:
> 
> - What do we mean by merged-/usr? (We already said this in #914897, but
>   I think it's worth reiterating that symlink farms are not it.)

This is defined (again) by
https://salsa.debian.org/debian/tech-ctte/-/blob/master/994388_merged_usr_advice/draft.md#definitions-and-current-status

> - Is it OK for packages in testing/unstable during Debian 12 development
>   to assume/require a merged-/usr system? (tl;dr: some maintainers think
>   the answer is yes, but I think the answer is no.)
>
> - When will it be OK for packages in testing/unstable to assume/require
>   a merged-/usr system? (tl;dr: some maintainers think the answer is
>   "right now", but I think the answer is "when the Debian 13 cycle begins"
>   and not before.)

Both of these are addressed by
https://salsa.debian.org/debian/tech-ctte/-/blob/master/994388_merged_usr_advice/draft.md#upgrade-path-from-debian-11-to-debian-12

> - Should maintainers proactively move files in packages from the root
>   filesystem into /usr? (tl;dr: I think they should not, at least until
>   the implications are better-understood.)
> 
> - Should maintainers of tools, e.g. debootstrap, proactively move files
>   in packages from the root filesystem into /usr, e.g. systemd system units?
>   (tl;dr: I think they should not.)

Both of these are addressed by
https://salsa.debian.org/debian/tech-ctte/-/blob/master/994388_merged_usr_advice/draft.md#moratorium-on-moving-files-logical-locations-into-usr

> - Are packages built on a merged-/usr system required to work correctly
>   on a non-merged-/usr system? If they are not, is it RC?
>   (I think they are required to work, and it should usually be RC if
>   they don't)

https://salsa.debian.org/debian/tech-ctte/-/blob/master/994388_merged_usr_advice/draft.md#building-packages

On Thu, 16 Sep 2021 at 15:35:11 -0700, Sean Whitton wrote:
> You write:
> 
> >> - Because Debian 11 installations with the non-merged-/usr layout already
> >>   exist, all packages in Debian 12 should be installable onto a 
> >> non-merged-/usr
> >>   system along with their dependencies, and work correctly on the resulting
> >>   system.
> 
> (1) The reason for this, to put it a bit simplistically, is that we
> don't require apt to perform the upgrade between stable releases in any
> particular order, right?  Or are there other reasons distinct from this
> one that I'm missing?  I think it would be good to state the thing about
> apt (in better language than mine) in the text.

I think that's the main reason. We have not traditionally mandated
the use of a special upgrade tool like Ubuntu's do-release-upgrade(8),
so the upgrade happens in whatever order apt chooses, which can vary
between machines.

Another reason why I think we want Debian 12 packages to be installable
onto non-merged-/usr systems is that to be able to do our development work,
they need to be installable onto testing/unstable systems, which (again)
means that the upgrade order is undefined.

We also have best-effort support for partial upgrades, either oldstable
-> stable or stable -> testing/unstable: upgrading only a subset of the
available packages, plus their mandatory dependencies, but without also
upgrading apparently-unrelated packages. This can only ever be partially
supported, because it leads to a combinatorial explosion of possible
partially-upgraded systems, and realistically we can never test them all;
but I think it's best if we try to avoid knowingly making this worse.

Finally, there is a reason to want this that is circular in nature: if we
want Debian 12 packages to be installable onto non-merged-/usr systems,
and we want to be able to say with reasonable confidence that we think
they work in that situation, then we need to be able to test that they
do, in fact, work. As mentioned under the "Testing and QA" heading,
if we do not keep it possible to force autopkgtest VMs/containers,
piuparts chroots, reproducible-builds chroots and manual-test VMs (or
even scratch installations on real hardware) to be non-merged-/usr,
then we will have trouble testing that. However, I have tried to make it
clear that if a developer sets up such a system, they cannot expect to
be able to upgrade it cleanly to Debian 13, or to a post-Debian-12
state of testing/unstable.

> (2) Some people on -devel would seem to think that we can have smooth
> upgrades from bullseye to bookworm without requiring 

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

[Sean Whitton]

Hello,

On Wed 15 Sep 2021 at 12:35PM +01, Simon McVittie wrote:

> On Wed, 15 Sep 2021 at 11:46:11 +0100, Simon McVittie wrote:
>> As for what that advice is, I'm open to suggestions, but I'm drafting
>> some possible wording, which I'll upload to
>> https://salsa.debian.org/debian/tech-ctte/ when I have a bug number
>> for it.
>
> Here it is:
>
> https://salsa.debian.org/debian/tech-ctte/-/blob/master/994388_merged_usr_advice/draft.md

Thank you very much for this.

> This is a collection of various pieces of advice. I hope that this is
> sufficiently uncontroversial among the TC that we can improve the wording
> where necessary, then take a unanimous or close-to-unanimous vote
> "yes > further discussion" when we feel that it reflects consensus?

I think so, yes.

> If there are individual bits that are more contentious, then I suggest
> we vote on them as formally or informally as we are comfortable
> with, then make the formal resolution reflect the results of those
> votes; alternatively, we could kick out anything more controversial into
> a separate resolution if we need to.

Both those options seem reasonable.

> - §(Upgrade path from Debian 11 to Debian 12): Does everyone agree
>   with what I've written here about the implications of #978636?
>
>   I've tried to be careful to distinguish between the Debian 12
>   stable release and the state of testing/unstable during the development
>   cycle; better wordsmithing welcome.

The implications of this distinction is the main point of contention in
the -devel discussions, so far as I can tell.  I've two things to ask.
You write:

>> - Because Debian 11 installations with the non-merged-/usr layout already
>>   exist, all packages in Debian 12 should be installable onto a 
>> non-merged-/usr
>>   system along with their dependencies, and work correctly on the resulting
>>   system.

(1) The reason for this, to put it a bit simplistically, is that we
don't require apt to perform the upgrade between stable releases in any
particular order, right?  Or are there other reasons distinct from this
one that I'm missing?  I think it would be good to state the thing about
apt (in better language than mine) in the text.

(2) Some people on -devel would seem to think that we can have smooth
upgrades from bullseye to bookworm without requiring support for
non-merged-/usr in every single package in bookworm, i.e., without
supporting non-merged-/usr for testing/unstable installations during the
current release cycle.

What smcv has been arguing for is the most conservative option.  But
which of the following is it the TC wants to say:

- we are sure that this is the only way to ensure smooth upgrades, such
  that it pretty much follows from our previous decision on merged-/usr

- we think there might be viable alternatives to requiring every package
  in bookworm to work on both layouts, but we aren't sure they are safe
  enough, so we're recommending a simple and conservative approach

- we think that ensuring non-merged-/usr testing/unstable installations
  work during this release cycle is reason enough to take this highly
  conservative approach

?

> - §(Upgrade path from Debian 11 to Debian 12): Is the last paragraph
>   "If a suitable transition mechanism is not available by the time the
>   Debian 12 freeze is reached..." necessary, or is it implicit that
>   *obviously* we won't demand that the project carries on with merged-/usr
>   if it turns out not to be possible?

No, it's good to have that text.

> - §(Building packages): Does everyone agree with my interpretation of
>   what we agreed in #914897 and its implications? Do we need to make a
>   recommendation for the Debian 12 development cycle, or is it enough
>   to assume that the "middle" option that we resolved in #914897
>   continues to be our opinion?

I think that the other things said above mean that no-one would think
the situation with regard to building packages has changed since the
Debian 11 cycle.

>   I assume our advice power doesn't extend to unilaterally declaring
>   a class of bugs to be RC, but we can certainly advise the release team
>   and package maintainers that they *should* consider a class of bugs
>   to be RC; if they follow our advice, great, and if they don't, we can
>   consider whether we need to overrule in individual cases.

Agreed.

> - §(Moratorium on moving files' logical locations into /usr):
>   I think we should stop moving files into /usr on an individual basis,
>   at least until the consequences are fully understood, and perhaps for
>   the whole Debian 12 release cycle (after which, assuming merged-/usr
>   goes as we have recommended, maintainers can swap their logical location
>   without needing a transitional mechanism any more). Implementing
>   merged-/usr as the only supported layout means that moving files into
>   /usr on an individual basis is mostly unnecessary, because it has no
>   practical effect any more.

The case you make for this is 

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

[Simon McVittie]

On Wed, 15 Sep 2021 at 11:34:33 -0400, Zack Weinberg wrote:
> For the various files with a "canonical" location
> either in /usr or in /, either specified by some standard or by
> convention, and regularly referred to by absolute pathname, all
> software should continue to refer to those files by their "canonical"
> name

There are two sorts of hard-coding that are common for absolute paths,
which we should not conflate.

I think you might be primarily talking about the situation where source
code refers to an executable by its hard-coded absolute path? (As in
"#!" of a script that is installed unmodified, as opposed to being
generated from a template.)

The situation I was talking about is where a build system auto-detects
the "correct" location for some tool, such as sed or perl, and writes
that detected location into an installed file - for example reading a
template that starts with #!@PERL@ and outputting an executable script
that starts with #!/usr/bin/perl, or similar. When this happens in a
binary package system like .deb, we need to make sure that the location
that will be detected on the build system is correct for all systems
where the .deb could get installed, even if the /usr-merge status of
the build system and the installed system are different (and we need to
continue to do this as long as both merged-/usr and non-merged-/usr are
supported). Upstreams that do this auto-detection are often trying to
help the use-case of portability of a single set of source code between
OSs, but unfortunately the auto-detection is sometimes unhelpful when a
single binary package is expected to support being installed on multiple
dissimilar but equally-supported OS configurations.

In both of these cases, during the transitional period that ends when
merged-/usr becomes required, package maintainers need to make sure
(by patching the source code, or configuring the build system, or
whatever other method is most suitable) that the package they maintain
will continue to work on non-merged-/usr Debian systems. There is no
requirement that Debian packages are portable to non-Debian systems,
however.

> The most common class of such files is
> those used in #! directives: /bin/sh not /usr/bin/sh, /usr/bin/perl
> not /bin/perl, etc.  I would ideally like this to be spelled out in
> Policy, as an explicit list of files that MUST be referred to without
> /usr, all others to be referred to with /usr.

A comprehensive list of executables whose paths in /{s,}bin can/should
be hard-coded seems at first glance as though it would be too large to
be particularly useful: on my x86_64 system, `apt-file search` tells
me it can see 245 files in /bin and 549 in /sbin. I'm confident that
many (most?) of those cannot be relied on to be in /bin,/sbin in all
non-Debian OSs.

As a 90% solution, it might be worthwhile to have a non-comprehensive
list of common interpreters and their canonical paths, but I think
Lintian is better-placed than Policy to do that, and it already has a list.

> As an upstream contributor to several pieces of software included in
> Debian, and as someone with an interest in ensuring that software
> developed on Linux is not *accidentally* unportable to other OSes
> under the 'Unix' umbrella, I'd like to stick an oar in

Sorry, I think portability to other Unixes is outside Debian's scope. One
of the advantages of merged /usr is that this is no longer something we
have to argue with each upstream that does not use (our idea of) the
canonical paths for everything, because both /bin and /usr/bin paths
will work.

With upstream hat on, I think this is going to be a losing battle in
general, because outside a few narrow areas that are fixed by Unix
folk history (mainly /bin/sh and /usr/bin/env), there is no portable
canonical path. For example, I regularly see merge requests to various
upstream projects saying that #!/bin/bash is not sufficiently portable
and they need to use #!/usr/bin/env bash on some OS - but in Debian,
we often prefer #!/bin/bash, to avoid packaged scripts being broken by
a locally-installed and potentially incompatible /usr/local/bin/bash.

smcv

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

[Sam Hartman]

> "Simon" == Simon McVittie  writes:

Simon> Package: tech-ctte Severity: normal

Simon> As discussed in our last meeting, I think we should issue
Simon> more specific advice about merged-/usr, and in particular
Simon> about what #978636 means for maintainers right now.

I wasn't at this meeting, but as someone who has followed the merged
/usr discussions reasonably closely, I'd like to second the idea of
giving this advice.


I think we had a very productive discussion on debian-devel.
I think with a round or two more we could confirm project consensus on
some of the areas where you propose to give advice.

Honestly, though, I think  that having the TC give a decision in this
instance will be more effective and will take up less time overall.

I think the advice you propose to give is consistent with project
consensus where there is a consensus.  I think there are a couple of
areas, like gradual migration of paths where there is no rough consensus.  In
particular, I think Neils is not the only one who is uncomfortable
assuming that dpkg changes will eventually come along to better support
aliasing.
In those areas, advice is needed, and the TC is a body that can give
that advice.
The advice you are proposing to give seems technically sound to me.

So, thanks very much for your hard work on this issue!


signature.asc
Description: PGP signature

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

[Zack Weinberg]

As a Debian user I'm pleased to see the ctte taking proactive steps to
ensure that the merged-/usr transition will still allow smooth
upgrades from Debian 11 to 12 and 12 to 13.

As an upstream contributor to several pieces of software included in
Debian, and as someone with an interest in ensuring that software
developed on Linux is not *accidentally* unportable to other OSes
under the 'Unix' umbrella, I'd like to stick an oar in regarding:

On Wed, 15 Sep 2021 at 12:39:53 +0100, Simon McVittie wrote:
> On Wed, 15 Sep 2021 at 12:35:38 +0100, Simon McVittie wrote:
> > - §(Building packages): I almost wrote an extra paragraph about
> >   how this class of bugs becomes a non-issue when merged-/usr is
> >   the only supported layout - but actually it doesn't! If we
> >   consider building packages while having /usr/local/bin/sed to be
> >   a supported thing you can do, then we need to ensure that
> >   /usr/local/bin/sed doesn't get hard-coded into the resulting
> >   package, and the steps you take to make that happen are the same
> >   as the steps you take to fix this class of bugs.
>
> I think that class of bugs probably does become non-RC when the
> merged-/usr transition is complete, though.

After the transition is complete, /usr/local is not the only possible
source of problems.  For the various files with a "canonical" location
either in /usr or in /, either specified by some standard or by
convention, and regularly referred to by absolute pathname, all
software should continue to refer to those files by their "canonical"
name, so that it remains portable to Unixes that have not and may
never undergo a /usr merge.  The most common class of such files is
those used in #! directives: /bin/sh not /usr/bin/sh, /usr/bin/perl
not /bin/perl, etc.  I would ideally like this to be spelled out in
Policy, as an explicit list of files that MUST be referred to without
/usr, all others to be referred to with /usr.

[I agree that from Debian's perspective it makes sense for these bugs
to be RC until the transition is complete, and non-RC afterward.]

zw

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

[Simon McVittie]

On Wed, 15 Sep 2021 at 12:35:38 +0100, Simon McVittie wrote:
> - §(Building packages): I almost wrote an extra paragraph about how
>   this class of bugs becomes a non-issue when merged-/usr is the only
>   supported layout - but actually it doesn't! If we consider building
>   packages while having /usr/local/bin/sed to be a supported thing you
>   can do, then we need to ensure that /usr/local/bin/sed doesn't get
>   hard-coded into the resulting package, and the steps you take to
>   make that happen are the same as the steps you take to fix this class
>   of bugs.

I think that class of bugs probably does become non-RC when the
merged-/usr transition is complete, though.

smcv

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

[Simon McVittie]

On Wed, 15 Sep 2021 at 11:46:11 +0100, Simon McVittie wrote:
> As for what that advice is, I'm open to suggestions, but I'm drafting
> some possible wording, which I'll upload to
> https://salsa.debian.org/debian/tech-ctte/ when I have a bug number
> for it.

Here it is:

https://salsa.debian.org/debian/tech-ctte/-/blob/master/994388_merged_usr_advice/draft.md

Edits and merge requests welcome. I suggest we use merge requests for
substantive changes.

This is a collection of various pieces of advice. I hope that this is
sufficiently uncontroversial among the TC that we can improve the wording
where necessary, then take a unanimous or close-to-unanimous vote
"yes > further discussion" when we feel that it reflects consensus?

If there are individual bits that are more contentious, then I suggest
we vote on them as formally or informally as we are comfortable
with, then make the formal resolution reflect the results of those
votes; alternatively, we could kick out anything more controversial into
a separate resolution if we need to.

Because this is advice to maintainers about decisions that, in some cases,
they are making right now, I would like to keep this moving and try to
reach a consensus we can announce to debian-devel-announce soon.

Questions for the committee:

- §(Definitions and current status): Does everyone agree with my
  characterization of where we are now?

- §(Upgrade path from Debian 11 to Debian 12): Does everyone agree
  with what I've written here about the implications of #978636?

  I've tried to be careful to distinguish between the Debian 12
  stable release and the state of testing/unstable during the development
  cycle; better wordsmithing welcome.

- §(Upgrade path from Debian 11 to Debian 12): Is the last paragraph
  "If a suitable transition mechanism is not available by the time the
  Debian 12 freeze is reached..." necessary, or is it implicit that
  *obviously* we won't demand that the project carries on with merged-/usr
  if it turns out not to be possible?

- §(Testing and QA): Do we want to recommend this?

- §(Building packages): Does everyone agree with my interpretation of
  what we agreed in #914897 and its implications? Do we need to make a
  recommendation for the Debian 12 development cycle, or is it enough
  to assume that the "middle" option that we resolved in #914897
  continues to be our opinion?

  I assume our advice power doesn't extend to unilaterally declaring
  a class of bugs to be RC, but we can certainly advise the release team
  and package maintainers that they *should* consider a class of bugs
  to be RC; if they follow our advice, great, and if they don't, we can
  consider whether we need to overrule in individual cases.

- §(Building packages): I almost wrote an extra paragraph about how
  this class of bugs becomes a non-issue when merged-/usr is the only
  supported layout - but actually it doesn't! If we consider building
  packages while having /usr/local/bin/sed to be a supported thing you
  can do, then we need to ensure that /usr/local/bin/sed doesn't get
  hard-coded into the resulting package, and the steps you take to
  make that happen are the same as the steps you take to fix this class
  of bugs.

- §(Moratorium on moving files' logical locations into /usr):
  I think we should stop moving files into /usr on an individual basis,
  at least until the consequences are fully understood, and perhaps for
  the whole Debian 12 release cycle (after which, assuming merged-/usr
  goes as we have recommended, maintainers can swap their logical location
  without needing a transitional mechanism any more). Implementing
  merged-/usr as the only supported layout means that moving files into
  /usr on an individual basis is mostly unnecessary, because it has no
  practical effect any more.

  Note that my opinion on this is consistent with Adrian's request
  to overrule the debianutils maintainer and require installkernel
  and run-parts to be moved back to the rootfs. We should make sure
  that whatever we decide here is consistent with the way in which we
  overrule or decline to overrule the debianutils maintainer.

> - Should maintainers of tools, e.g. debootstrap, proactively move files
>   in packages from the root filesystem into /usr, e.g. systemd system units?
>   (tl;dr: I think they should not.)

Ansgar pointed out on IRC that of course I meant to say debhelper here, not
debootstrap. The version of debhelper in git reverts the change that
previously moved systemd units from /lib/systemd/system into
/usr/lib/systemd/system, but at the time of writing that revert is not
in a release.

smcv

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

[Simon McVittie]

Package: tech-ctte
Severity: normal

As discussed in our last meeting, I think we should issue more specific
advice about merged-/usr, and in particular about what #978636 means for
maintainers right now.

Constitutionally, I'm asking the TC to use its power to offer formal
advice (Debian constitution, §6.1.5).

As for what that advice is, I'm open to suggestions, but I'm drafting
some possible wording, which I'll upload to
https://salsa.debian.org/debian/tech-ctte/ when I have a bug number
for it.

Some questions that I think we need to answer explicitly:

- What do we mean by merged-/usr? (We already said this in #914897, but
  I think it's worth reiterating that symlink farms are not it.)

- Is it OK for packages in testing/unstable during Debian 12 development
  to assume/require a merged-/usr system? (tl;dr: some maintainers think
  the answer is yes, but I think the answer is no.)

- When will it be OK for packages in testing/unstable to assume/require
  a merged-/usr system? (tl;dr: some maintainers think the answer is
  "right now", but I think the answer is "when the Debian 13 cycle begins"
  and not before.)

- Should maintainers proactively move files in packages from the root
  filesystem into /usr? (tl;dr: I think they should not, at least until
  the implications are better-understood.)

- Should maintainers of tools, e.g. debootstrap, proactively move files
  in packages from the root filesystem into /usr, e.g. systemd system units?
  (tl;dr: I think they should not.)

- Are packages built on a merged-/usr system required to work correctly
  on a non-merged-/usr system? If they are not, is it RC?
  (I think they are required to work, and it should usually be RC if
  they don't; constitutionally I don't think we can unilaterally declare
  a class of bugs to be RC, at least not while using our "advice" power,
  but we can certainly recommend that maintainers and the release team
  should consider them to be RC.)

smcv