Re: Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Didier 'OdyX' Raboud]

Le lundi, 4 mars 2019, 22.28:38 h CET Margarita Manterola a écrit :
> Hi,
> 
> > - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> > 
> > The winners are:
> >  Option M `middle`
> >  Option H `hard`
> > 
> > - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> > 
> > Dear Marga, as Chair, could you please make use of your casting vote to
> > break this tie?
> 
> I'm using my casting vote to vote in favor of M `middle` (i.e. consider
> that the desirable situation at the time of bullseye is that both directory
> schemes are allowed, all packages can be built on either).
> 
> My rationale for taking this decision is as follows:
> 
> Right now we are not ready to migrate to building on merged-usr systems in
> Debian, there are still 29 known packages that are broken and need to be
> fixed.  My expectation is that those packages will be fixed in the not so
> distant future (i.e.  before bullseye) and that after that, the buildd
> profile in debootstrap will default to having a merged /usr, so that new
> buildd chroots will use that setup.
> 
> However, we have no control over how fast individual developers and
> derivative distributions will migrate to the new format. It's possible that
> more time will be required until everyone is ready to migrate.
> 
> Additionally, as of our current understanding of the issue, there are no
> known problems for building on a non-merged system. Supporting this
> setup does not imply additional work from the point of view of our
> maintainers (for now).
> 
> In the future, it would be a bug if a problem is discovered with building a
> package on a non-merged /usr system. I understand that this would mean
> additional work to the maintainers of such a package, but at least as of
> today this is a non-issue. Eventually, when fixing such bugs becomes a
> significant burden for our maintainers, it can be decided that the setup is
> no-longer supported, but my personal recommendation would be to wait at
> least until bullseye+1. That's why I'm voting "Middle" for bullseye.

I have announced this decision on debian-devel-announce:
https://lists.debian.org/debian-devel-announce/2019/03/msg1.html

I am therefore hereby closing this bug.

Thank you to all involved parties!

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Margarita Manterola]

Hi,

> - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 
> The winners are:
>Option M `middle`
>Option H `hard`
> 
> - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 
> Dear Marga, as Chair, could you please make use of your casting vote to break 
> this tie?

I'm using my casting vote to vote in favor of M `middle` (i.e. consider
that the desirable situation at the time of bullseye is that both directory
schemes are allowed, all packages can be built on either).

My rationale for taking this decision is as follows:

Right now we are not ready to migrate to building on merged-usr systems in
Debian, there are still 29 known packages that are broken and need to be
fixed.  My expectation is that those packages will be fixed in the not so
distant future (i.e.  before bullseye) and that after that, the buildd
profile in debootstrap will default to having a merged /usr, so that new
buildd chroots will use that setup.

However, we have no control over how fast individual developers and
derivative distributions will migrate to the new format. It's possible that
more time will be required until everyone is ready to migrate.

Additionally, as of our current understanding of the issue, there are no
known problems for building on a non-merged system. Supporting this
setup does not imply additional work from the point of view of our
maintainers (for now).

In the future, it would be a bug if a problem is discovered with building a
package on a non-merged /usr system. I understand that this would mean
additional work to the maintainers of such a package, but at least as of
today this is a non-issue. Eventually, when fixing such bugs becomes a
significant burden for our maintainers, it can be decided that the setup is
no-longer supported, but my personal recommendation would be to wait at
least until bullseye+1. That's why I'm voting "Middle" for bullseye.

-- 
Thanks,
Marga


signature.asc
Description: PGP signature

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Didier 'OdyX' Raboud]

Le lundi, 25 février 2019, 14.58:09 h CET Didier 'OdyX' Raboud a écrit :
> I call for vote immediately on the following resolution.
> 
> === Resolution ===
> 
> The Technical Committee resolves to decline to override the debootstrap
> maintainers.
> 
> Furthermore, using its §6.1.5 "Offering advice" power, the Technical
> Committee considers that the desirable solution at the time of `bullseye`
> is:
> 
> * W: `weak`: both directory schemes are allowed, but packages should only
>  be built on hosts with classical directory schemes (or in such
>  chroots)
> 
> * M: `middle`: both directory schemes are allowed, and packages (including
>official packages) can be built on hosts with either
> classical or "merged `/usr`" directory schemes
> 
> * H: `hard`: both directory schemes are allowed, but packages should only
>  be built on hosts with "merged `/usr`" directory schemes (or in
> such chroots)
> 
> * FD: Further Discussion
> 
> === End Resolution ===

Dear all,

with 6 votes in, and one week gone, the outcome of this vote is still in 
doubt; here's an abstract of the vote calculation (a clearsigned verbose 
version is attached):

/--WMHF
V: 3214 odyx
V: 2134 bremner
V: 4213 gwolf
V: 3124 ntyni
V: 2134 marga
V: 4213 fil
  Option
  W M H F 
===   ===   ===   === 
Option W0 2 4 
Option M  6   3 6 
Option H  4 3   6 
Option F  2 0 0   

Option W Reached quorum: 4 >= 2
Option M Reached quorum: 6 >= 2
Option H Reached quorum: 6 >= 2

Option W passes Majority.   2.000 (4/2) > 1

  Option M defeats Option W by (   6 -0) =6 votes.
  Option H defeats Option W by (   4 -2) =2 votes.
  Option W defeats Option F by (   4 -2) =2 votes.
  Option M defeats Option F by (   6 -0) =6 votes.
  Option H defeats Option F by (   6 -0) =6 votes.

- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

The winners are:
 Option M `middle`
 Option H `hard`

- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=


So. We have a tie, and the voting period is over. I am quite confident we can 
neither continue discussing (FD lost to M and H unanimously, and to W by 2), 
nor allow smcv to vote (the voting period is over). We're left with the 
Chair's casting vote (as per §6.3.2). So…

Dear Marga, as Chair, could you please make use of your casting vote to break 
this tie?

Cheers,
OdyX-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Starting results calculation at Mon Mar  4 15:34:31 2019

/--WMHF
V: 3214 odyx
V: 2134 bremner
V: 4213 gwolf
V: 3124 ntyni
V: 2134 marga
V: 4213 fil
Option W "`weak`: both directory schemes are allowed, but packages should only 
be built on hosts with classical directory schemes (or in such chroots)"
Option M "`middle`: both directory schemes are allowed, and packages (including 
official packages) can be built on hosts with either classical or "merged 
`/usr`" directory schemes"
Option H "`hard`: both directory schemes are allowed, but packages should only 
be built on hosts with "merged `/usr`" directory schemes (or in such chroots)"
Option F "Further Discussion"

In the following table, tally[row x][col y] represents the votes that
option x received over option y.

  Option
  W M H F 
===   ===   ===   === 
Option W0 2 4 
Option M  6   3 6 
Option H  4 3   6 
Option F  2 0 0   



Looking at row 2, column 1, M
received 6 votes over W

Looking at row 1, column 2, W
received 0 votes over M.

Option W Reached quorum: 4 >= 2
Option M Reached quorum: 6 >= 2
Option H Reached quorum: 6 >= 2


Option W passes Majority.   2.000 (4/2) > 1


  Option M defeats Option W by (   6 -0) =6 votes.
  Option H defeats Option W by (   4 -2) =2 votes.
  Option W defeats Option F by (   4 -2) =2 votes.
  Option M defeats Option F by (   6 -0) =6 votes.
  Option H defeats Option F by (   6 -0) =6 votes.


The Schwartz Set contains:
 Option M "`middle`: both directory schemes are allowed, and packages 
(including official packages) can be built on hosts with either classical or 
"merged `/usr`" directory schemes"
 Option H "`hard`: both directory schemes are allowed, but packages 
should only be built on hosts with "merged `/usr`" directory schemes (or in 
such chroots)"



- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

The winners are:
 Option M "`middle`: both directory schemes are allowed, and packages 
(including official packages) can be built on hosts with either classical or 
"merged `/usr`" directory schemes"
 Option H "`hard`: both directory 

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Philip Hands]

Didier 'OdyX' Raboud  writes:

> Dear Technical Committee members,
>
> I call for vote immediately on the following resolution.
>
> === Resolution ===
>
> The Technical Committee resolves to decline to override the debootstrap
> maintainers.
>
> Furthermore, using its §6.1.5 "Offering advice" power, the Technical
> Committee considers that the desirable solution at the time of `bullseye` is:
>
> * W: `weak`: both directory schemes are allowed, but packages should only
>  be built on hosts with classical directory schemes (or in such
>  chroots)
>
> * M: `middle`: both directory schemes are allowed, and packages (including
>official packages) can be built on hosts with either classical
>or "merged `/usr`" directory schemes
>
> * H: `hard`: both directory schemes are allowed, but packages should only
>  be built on hosts with "merged `/usr`" directory schemes (or in
>  such chroots)
>
> * FD: Further Discussion
>
> === End Resolution ===

I vote:

  H > M > FD > W

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Margarita Manterola]

> === Resolution ===
> 
> The Technical Committee resolves to decline to override the debootstrap
> maintainers.
> 
> Furthermore, using its §6.1.5 "Offering advice" power, the Technical
> Committee considers that the desirable solution at the time of `bullseye` is:
> 
> * W: `weak`: both directory schemes are allowed, but packages should only
>  be built on hosts with classical directory schemes (or in such
>  chroots)
> 
> * M: `middle`: both directory schemes are allowed, and packages (including
>official packages) can be built on hosts with either classical
>or "merged `/usr`" directory schemes
> 
> * H: `hard`: both directory schemes are allowed, but packages should only
>  be built on hosts with "merged `/usr`" directory schemes (or in
>  such chroots)
> 
> * FD: Further Discussion
> 
> === End Resolution ===

I vote:

M > W > H > FD

-- 
  Marga


signature.asc
Description: PGP signature

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Niko Tyni]

On Mon, Feb 25, 2019 at 02:58:09PM +0100, Didier 'OdyX' Raboud wrote:

> === Resolution ===
> 
> The Technical Committee resolves to decline to override the debootstrap
> maintainers.
> 
> Furthermore, using its §6.1.5 "Offering advice" power, the Technical
> Committee considers that the desirable solution at the time of `bullseye` is:
> 
> * W: `weak`: both directory schemes are allowed, but packages should only
>  be built on hosts with classical directory schemes (or in such
>  chroots)
> 
> * M: `middle`: both directory schemes are allowed, and packages (including
>official packages) can be built on hosts with either classical
>or "merged `/usr`" directory schemes
> 
> * H: `hard`: both directory schemes are allowed, but packages should only
>  be built on hosts with "merged `/usr`" directory schemes (or in
>  such chroots)
> 
> * FD: Further Discussion
> 
> === End Resolution ===

I vote:

  M > H > W > FD

-- 
Niko Tyni   nt...@debian.org


signature.asc
Description: PGP signature

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Gunnar Wolf]

Didier 'OdyX' Raboud dijo [Mon, Feb 25, 2019 at 02:58:09PM +0100]:
> === Resolution ===
> 
> The Technical Committee resolves to decline to override the debootstrap
> maintainers.
> 
> Furthermore, using its §6.1.5 "Offering advice" power, the Technical
> Committee considers that the desirable solution at the time of `bullseye` is:
> 
> * W: `weak`: both directory schemes are allowed, but packages should only
>  be built on hosts with classical directory schemes (or in such
>  chroots)
> 
> * M: `middle`: both directory schemes are allowed, and packages (including
>official packages) can be built on hosts with either classical
>or "merged `/usr`" directory schemes
> 
> * H: `hard`: both directory schemes are allowed, but packages should only
>  be built on hosts with "merged `/usr`" directory schemes (or in
>  such chroots)
> 
> * FD: Further Discussion
> 
> === End Resolution ===

My vote is:

H > M > FD > W


signature.asc
Description: PGP signature

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[David Bremner]

Didier 'OdyX' Raboud  writes:

> === Resolution ===
>
> The Technical Committee resolves to decline to override the debootstrap
> maintainers.
>
> Furthermore, using its §6.1.5 "Offering advice" power, the Technical
> Committee considers that the desirable solution at the time of `bullseye` is:
>
> * W: `weak`: both directory schemes are allowed, but packages should only
>  be built on hosts with classical directory schemes (or in such
>  chroots)
>
> * M: `middle`: both directory schemes are allowed, and packages (including
>official packages) can be built on hosts with either classical
>or "merged `/usr`" directory schemes
>
> * H: `hard`: both directory schemes are allowed, but packages should only
>  be built on hosts with "merged `/usr`" directory schemes (or in
>  such chroots)
>
> * FD: Further Discussion
>
> === End Resolution ===

I vote M > W > H > FD



signature.asc
Description: PGP signature

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Didier 'OdyX' Raboud]

Le lundi, 25 février 2019, 14.58:09 h CET Didier 'OdyX' Raboud a écrit :
> === Resolution ===
> 
> The Technical Committee resolves to decline to override the debootstrap
> maintainers.
> 
> Furthermore, using its §6.1.5 "Offering advice" power, the Technical
> Committee considers that the desirable solution at the time of `bullseye`
> is:
> 
> * W: `weak`: both directory schemes are allowed, but packages should only
>  be built on hosts with classical directory schemes (or in such
>  chroots)
> 
> * M: `middle`: both directory schemes are allowed, and packages (including
>official packages) can be built on hosts with either
>classical or "merged `/usr`" directory schemes
> 
> * H: `hard`: both directory schemes are allowed, but packages should only
>  be built on hosts with "merged `/usr`" directory schemes (or in
>  such chroots)
> 
> * FD: Further Discussion
> 
> === End Resolution ===

I vote:

H > M > W > FD

OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Didier 'OdyX' Raboud]

Dear Technical Committee members,

I call for vote immediately on the following resolution.

=== Resolution ===

The Technical Committee resolves to decline to override the debootstrap
maintainers.

Furthermore, using its §6.1.5 "Offering advice" power, the Technical
Committee considers that the desirable solution at the time of `bullseye` is:

* W: `weak`: both directory schemes are allowed, but packages should only
 be built on hosts with classical directory schemes (or in such
 chroots)

* M: `middle`: both directory schemes are allowed, and packages (including
   official packages) can be built on hosts with either classical
   or "merged `/usr`" directory schemes

* H: `hard`: both directory schemes are allowed, but packages should only
 be built on hosts with "merged `/usr`" directory schemes (or in
 such chroots)

* FD: Further Discussion

=== End Resolution ===



=== Rationale ===

## What is "merged `/usr`"

"Merged `/usr`" describes a possible future standard directories scheme in
which the `/{bin,sbin,lib*}/` directories have been made superfluous through
replacing them by symlinks to their `/usr` equivalents
(`/usr/{bin,sbin,lib*}`).
The motivation to get Debian systems to converge towards such a scheme is
vastly documented elsewhere ([FDO's TheCaseForTheUsrMerge][0],
[wiki.d.o UsrMerge][1]) but can be summarized as the following points:

* having separate `/` and `/usr` filesystems has been useful in the past for
booting without initramfs onto a minimal root filesystem that carried just
enough to mount the `/usr` filesystem later in the boot process. Given the
evolution of physical hosts' capabilities, initramfs'es have been default in
Debian (and elsewhere) for a long time, and most systems no longer have an
intermediate state during boot in which they have only `/`, but not `/usr`,
mounted. Booting hosts through that intermediate state is not systematically
tested in Debian anymore.
* another use-case is to share system files from `/usr` between hosts (over a
network link) or containers (locally) which use different data or
configuration. Having all software under `/usr` (instead of spread between
`/` and `/usr`) makes the centralized update and the sharing easier.
* the packaging infrastructure to install files outside of `/usr` (e.g.
installing libs under `/lib` instead of `/usr/lib`) is not standard and
represents technical debt.
* given its status as remnant "folklore", the distinction between what
_needs_ to be shipped in `/` and what can stay in `/usr` is often interpreted
arbitrarily;
* allowing shipment of identically-named libraries or binaries in different
paths can confuse common understanding of paths precedence.

[0]: https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
[1]: https://wiki.debian.org/UsrMerge

The arguments against moving the base directories' scheme towards "merged
`/usr`" are as follows:

* there's no gain in disrupting something that is not inherently broken;
* `/{bin,sbin,lib*}/` → `/usr/{bin,sbin,lib*}/` symlinks create confusing
views of the system (`/bin/cat` and `/usr/bin/cat` are the same file), and
dpkg doesn't support this situation cleanly:
[#134758](https://bugs.debian.org/134758).
* it is possible for distributions to converge towards having all system
files in `/usr` in finite time instead of shortcutting this migration with
`/{bin,sbin,lib*}/` → `/usr/{bin,sbin,lib*}/` symlinks.

The compatibility symbolic links `/lib` → `/usr/lib` and `/lib64` →
`/usr/lib64` are required by the various CPUs' platform ABIs (for example
i386 requires `/lib/ld-linux.so.2` to resolve to glibc's `ld.so`, and amd64
requires `/lib64/ld-linux-x86-64.so.2`) so there are no plans to remove them
altogether. Similarly, removing `/bin` is not under consideration because it
would break the assumption that `/bin/sh` exists, and removing `/sbin` would
break the assumption that `/sbin/fsck.*` and `/sbin/mount.*` exist.

## "merged `/usr`" in Debian

In Debian buster, the current testing suite, "merged `/usr`" is only
considered for implementation with symlinks (there are no proposals for
simply dropping `/{bin,sbin,lib*}`) and is implemented in two main ways:

* existing hosts can be made to have a "merged `/usr`" by installing the
[usrmerge][2] package;
* new hosts get the `/{bin,sbin,lib*}/`→ `/usr/{bin,sbin,lib*}/` symlinks
by default when using debootstrap >= 1.0.102.

The usrmerge package contains a `/usr/lib/convert-usrmerge` perl executable
that runs in `postinst`, that will move the contents of `/{bin,sbin,lib*}/`
and replace these directories with symlinks when empty.

It is also possible to merge `/usr` in other ways, for example with
`debootstrap --merged-usr` or by bootstrapping into a chroot that already
contains the necessary symlinks.

[2]: https://tracker.debian.org/pkg/usrmerge

## Issues from "merged `/usr`"

Since the default change in debootstrap 1.0.102, some issues 

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Didier 'OdyX' Raboud]

(Corrected the recipients, these mails should go to the bug).

Le lundi, 25 février 2019, 14.23:31 h CET Didier 'OdyX' Raboud a écrit :
> Le samedi, 23 février 2019, 12.12:13 h CET Niko Tyni a écrit :
> > > * B: The desireable solution at the time of bullseye is `hard`; both
> > > directory schemes should be allowed, and packages can be built on hosts
> > > with either classical or "merged-`/usr`" directory schemes.
> > 
> > Isn't this the 'middle' option above rather than 'hard'?
> 
> Actually, it's both.  The only difference between 'middle' and 'hard' is
> that in 'middle', _official_ packages can be built on either directory
> schemes, where in 'hard', they are only built on "merged-`/usr`" directory
> schemes.
> 
> The distinction I was trying to make in the table is the following:
> 
> * on which directory scheme Debian would build its "official" packages on
> (columns 5 & 6) ; 'weak' is "classical directory scheme", 'middle' is
> "both", 'hard' is "merged-/usr".
> * whether .debs built on A can break on B (columns 7 & 8).  All of 'weak',
> 'middle' and 'hard' long-term statuses allow .debs to be built from either
> directory scheme and be installed on either without constraints

Wrong, actually (hit send too fast). The intent behind 'weak' was: "merged-/
usr" is allowed, but packages built on these directory schemes can break on 
classical directory schemes.

So that should have read:

* whether .debs built on A can break on B (columns 7 & 8). 'middle' and 'hard' 
long-term statuses allow .debs to be built from either directory scheme and be 
installed on either without constraints; 'weak' permits "merged-/usr" 
directory schemes, but packages built there can break on classical directory 
schemes.

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Didier 'OdyX' Raboud]

Le samedi, 23 février 2019, 12.12:13 h CET Niko Tyni a écrit :
> > * B: The desireable solution at the time of bullseye is `hard`; both
> > directory schemes should be allowed, and packages can be built on hosts
> > with either classical or "merged-`/usr`" directory schemes.
> 
> Isn't this the 'middle' option above rather than 'hard'?

Actually, it's both.  The only difference between 'middle' and 'hard' is that 
in 'middle', _official_ packages can be built on either directory schemes, 
where in 'hard', they are only built on "merged-`/usr`" directory schemes.

The distinction I was trying to make in the table is the following:

* on which directory scheme Debian would build its "official" packages on 
(columns 5 & 6) ; 'weak' is "classical directory scheme", 'middle' is "both", 
'hard' is "merged-/usr".
* whether .debs built on A can break on B (columns 7 & 8).  All of 'weak', 
'middle' and 'hard' long-term statuses allow .debs to be built from either 
directory scheme and be installed on either without constraints

> FWIW I think I'm OK with recommending 'middle' but 'hard' seems over
> the top. Ideally there should be no difference in building on merged
> /usr hosts vs. classical ones.

I concur with your ideal. I'll add this option on the ballot.

> As for buster and overriding the debootstrap maintainers on the default:
> 
> I think being able to do local builds that work on other Debian
> systems with minimal fuss (no chroots etc.) is a desirable property
> but not an absolute requirement.  I'd certainly love to see all the
> 'paths_vary_due_to_usrmerge' issues fixed for buster [1].

I concur.

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Re: Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Didier 'OdyX' Raboud]

Le jeudi, 21 février 2019, 15.28:23 h CET Ian Jackson a écrit :
> Back in the wider world, of course many people build packages on
> Debian systems for installation `somewhere else'.  I have done it
> myself and probably many of the people reading this message have too.
> 
> What is implicitly going on here is that it is mostly-tacitly[2] being
> assumed (or declared) that `I built this .deb on my laptop[1] and gave
> it to my friend' is wrongheaded.

I don't think it is wrongheaded, but I do think that assuming that it is meant 
to work consistently under any circumstances, is.  There are _so many_ 
circumstances that make this exercise error-prone:

"I built this amd64 .deb and gave it to my friend for use on their RasbperryPi 
arm64 host"

"I built this .deb on my laptop on which I had installed a /usr/local/bin/
grep"

"I built this .deb an gave it to my friend who runs CentOS"

etc
 
> I don't think doing that is wrongheaded.  Certainly it is extremely
> common; we don't have any public pronouncements saying it is somehow
> wrong; and we have had little discussion where we as a project decided
> that this was now a use case which we feel free to just break.

Frankly, while it's not _broken_ per se, it is and has always really been 
fragile.  True, merged-/usr arguably worsens _one_ aspect of building packages 
on one's host, but in ways that are really easy to detect, and warn for.

> Personally I think that this is a very important thing to keep
> working.  It is the very core of users' collective software freedom.

You seem to be conflating "building on one's host" with "outside of any 
chroot", and equating this with "users' collective software freedom" is really 
making your point a disservice.  Being able to improve, build and share binary 
artifacts of free software is _vital_, and the whole point of building 
software distributions in the first place, but insisting that these rights are 
only "truly" exercised when builds are done outside of chroots is 
disingenuine. .deb packages already have to be built using certain tools, so 
we do set the limit (of what minimal set of tools are mandatory) somewhere, 
and my point is that this limit might not be at the right place. I'd be 
totally OK with saying "the only supported way to build .deb packages from 
buster on is using by pdebuild; however, you _can_ use dpkg-buildpackage 
alone, but be aware (and you'll get warnings) that this can lead to building 
.deb packages with undesireable properties."  The second half of the sentence 
is already true, and has always been; we probably just failed at communicating 
it sufficiently clearly.

> And that software freedom needs to be easy to exercise in practice.
> Despite a lot of excellent tooling, chroots are still not entirely
> trivial to set up and maintain.

Then that's maybe what we should be fixing.  

> I would invite the TC to read this manpage, which is trying to explain
> to a Debian user how to change the programs on their own computer
>   https://manpages.debian.org/stretch-backports/dgit/dgit-user.7.en.html
> and then consider how much even worse it would be if we had to write
> about chroots too.

Perhaps dpkg-buildpackage should be grown to build in a chroot by default? Or 
get an option to do that?

Really, I think we should stop considering that .debs built outside of 
"controlled environments" are more than temporary software transports. Our 
"standard" package building tools should build in such environments by 
default.

> To TC members who are minded to uphold the current approach, I would
> ask: can you please explicitly state your opinion on this ?  That is:
> 
>   Is it OK for a Debian user to build .deb on their laptop and give it
>   to their friend ?

Yes; provided that said .deb is built in a sane (sanitized / controlled) 
environment.  As you're talking about non-chroot builds; it is OK, provided 
that the tools warn about that. In that area, I think the "Build-Tainted-By" 
are steps in the right direction.

>   If it is OK, how will we make sure that it does not pointlessly break ?

As it is already broken in many ways, your question is biased. But I think the 
good way is to normalize "proper builds", by making sure our standard tools 
"do the right thing" by default.

> I readily admit that there are many ways that this can produce a
> result significantly different to the official Debian package,
> particularly because the package build system may configure itself
> differently in the the presence of unexpected.  The resulting package
> is probably not going to be suitable for wide distribution.
> 
> But those kind of problems are (a) not serious in practice
> (b) generally have obvious symptoms and (c) are easily worked around
> by various means.  Working around a usrmerge-generated failure is
> difficult; it usually involves doing serious violence to the upstream
> build system, or perhaps horrific rules file bodges.

Given a Build-Tainted-By flag in the binary 

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Didier 'OdyX' Raboud]

Le mardi, 19 février 2019, 01.59:18 h CET Steve McIntyre a écrit :
> While I'm not necessarily disagreeing with the overall point(s) here,
> some of the points in this list of arguments seem dubious at
> best. Maybe you could expand?

Sure. Sorry for publishing a new ballot before answering.

> >* booting with `/` only is not systematically tested in Debian anymore;
> 
> I'm assuming you mean "/ without /usr" here?

Yes. Clarified this point by merging it with the "separate / and /usr" one 
above.

> >* the packaging infrastructure to install files outside of `/usr` is not
> >  standard and represents technical debt:
> 
> I have no idea what you're suggesting here.

Same here (clarified in the ballot). What I'm trying to say here is that 
installing (e.g.) libs to /lib instead of /usr/lib is usually a deviation from 
standard software building (either in upstream packaging, or in debian/rules), 
that needs to be maintained on the long-term.

Cheers,
OdyX

signature.asc
Description: This is a digitally signed message part.

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Uoti Urpala]

On Sun, 24 Feb 2019 14:16:03 +0100 Johannes Schauer  wrote:
> I found that some important arguments are still missing. A recent mail by
> Guillem [1] nicely summarizes also many of my own thoughts. I'm going to paste
> the relevant content into this mail for convenience of the reader:

I think those have actually been addressed before, even if they're not
explicitly listed or refuted in the draft.

Guillem seems to accept moving away from current filesystem layout, but
also opposes the resulting layout used by other distributions (which
includes the /bin -> /usr/bin symlink). Do you share that view?

The main issue with Guillem's view is that in practice it would make
the transition more cumbersome and error-prone. If there is no
directory-level symlink, then migrating things requires either creating
individual symlinks for everything instead, or having a flag day to
make sure nothing references the old location any more. In practice
either of those is more problematic than a directory symlink.


> > 1) The merged-/usr-via-symlinks deployment method used by both
> >debootstrap and usrmerge, means that those systems will get
> >permanent filesystem aliasing problems, forever. Even when all
> >files might have been moved to their /usr counterparts in the
> >packages! This is due to the fact that different pathnames can
> >end up pointing (before any canonicalization!) to the same dentry.
> > 
> >This does not only affect dpkg (dpkg, dpkg-divert, dpkg-trigger,
> >etc), and update-alternatives (in a worse way), but any program
> >that uses pathanmes in the filesystem as keys in databases f.ex.

This has already been in use, both in Debian and in other
distributions, for quite some time. No major problems have been
reported. Arguing about "any program" is not useful when discussing
only Debian choices, because the layout is used by other distributions
in any case and programs have to cope.


> > 2) It bypasses the packaging system understanding of what is on the
> >filesystem and creates mismatches between what's on binary packages
> >and what's on disk.

This also has not caused major problems, but it can be solved
straightforwardly in dpkg if needed. Dpkg can special-case any legacy
/bin path contained in a package and internally change it to /usr/bin.


> > 3) Switching packages to the merged-/usr layout could have been
> >accomplished automatically via debhelper for a coverage of around
> >99% (?) of the archive. With something along the lines of:

This would just create a more cumbersome and error-prone migration.


> > 4) Due to having to support the broken merged-/usr-via-symlinks
> >deployment, when we want to move the contents of the binary
> >packages to the merged-/usr layout, we require now to include tons
> >of logic in (probably new) maintainer scripts, when we have been
> >trying to remove them altogether. :( With even more files untracked
> >by dpkg itself, bypassing the packaging system even more, when the
> >compat symlinks could have been shipped in the binary packages.

This seems to be based on questionable implicit assumptions. Namely
that the move would want to create an individual per-file compatibility
symlink in /bin for non-merged systems, and this is the part which
would cause problems. There seem to be neither technical reasons to
prefer non-merged systems for any use nor practical difficulties
migrating existing systems to the merged layout, so long-term it seems
OK to deal with this by just requiring merged-usr and not shipping any
individual compatibility links for non-merged systems. This allows the
simplest possible move - just install the files in /usr normally.


> > 5) Most new installations will not even benefit from this hacky and
> >rushed deployment, as long as they do not use a separate parition
> >for /usr!

Is there a point to this? Yes, migrating to merged /usr is mostly an
internal implementation detail for most users. But this does not
exactly give any argument against the migration, other than calling it
"hacky and rushed" while it seems to be the most practical way to do
things.


> > 6) The merged-/usr-via-symlinks deployment hack is irreversible right
> >now.

This is not a reason to avoid using the merged-usr layout.


> Just like Guillem, I'm personally not against merged-/usr but against how we
> implement it.

Not against, except for the directory symlinks being part of the
merged-usr layout?

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Ansgar]

Johannes Schauer writes:
> With how merged-/usr is getting deployed via debootstrap, we are placing more
> of the instructions of how a Debian system is supposed to be setup *outside* 
> of
> the packages themselves (and into debootstrap). It would make a cleaner design
> if we could have all necessary definitions of how to create a Debian chroot
> from scratch (on a Debian system) in the packages *themselves* instead of
> requiring code around the packages that is doing some magic setup (usually
> debootstrap).

One could drop the magic setup if merged-/usr was mandatory:

(1) have /bin -> /usr/bin symlinks shipped in base-files
(2) have all packages install to /usr

The additional complexity of having to setup symlinks outside the
packaging system comes from supporting both merged and nonmerged setups.

debootstrap or the usrmerge package implement some way to setup the
symlink which would not be necessary if they were included in the
packages; it would not be necessary if (1) was implemented (plus
handling system upgrades from legacy installations).

On merged-/usr systems, packages could just switch install location
gradually; they would install to the same location anyway, no compat
symlinks or maintainer script logic required.

Ansgar

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Johannes Schauer]

Hi,

On Sat, 02 Feb 2019 15:38:01 +0100 Didier 'OdyX' Raboud  wrote:
> Gunnar and myself have started working on a draft, the latest version of
> which is available at
> 
>   
> https://salsa.debian.org/debian/tech-ctte/blob/master/914897_merged_usr/ballot.md

I found that some important arguments are still missing. A recent mail by
Guillem [1] nicely summarizes also many of my own thoughts. I'm going to paste
the relevant content into this mail for convenience of the reader:

[1] https://lists.debian.org/20190219044924.gb21...@gaara.hadrons.org

Quoting Guillem Jover (2019-02-19 05:49:24)
> The underlaying problem with the merged-/usr-via-symlinks is not
> really that it has generated bugs, many transitions we perform incur
> those, for the better. The problem is that it has generated those when
> it was really not necessary in the first place, has made things
> unnecessarily more complicated for everyone, and it's a terrible hack
> trying to reap "quick" benefits at the cost of everyhing else, with
> long lasting consequences even after a full migration to /usr would
> have been finished. And here's why:
> 
> 1) The merged-/usr-via-symlinks deployment method used by both
>debootstrap and usrmerge, means that those systems will get
>permanent filesystem aliasing problems, forever. Even when all
>files might have been moved to their /usr counterparts in the
>packages! This is due to the fact that different pathnames can
>end up pointing (before any canonicalization!) to the same dentry.
> 
>This does not only affect dpkg (dpkg, dpkg-divert, dpkg-trigger,
>etc), and update-alternatives (in a worse way), but any program
>that uses pathanmes in the filesystem as keys in databases f.ex.
> 
> 2) It bypasses the packaging system understanding of what is on the
>filesystem and creates mismatches between what's on binary packages
>and what's on disk.
> 
> 3) Switching packages to the merged-/usr layout could have been
>accomplished automatically via debhelper for a coverage of around
>99% (?) of the archive. With something along the lines of:
> 
>  ,---
>  D=debian/tmp
>  for d in /bin /sbin /lib; do
>for p in $(find $D/$d ! -type d); do
>  b="${p##$D/}"
>  m="$D/usr$b"
>  if [ ! -e "$m" ]; then
>mkdir -p "$(dirname $m)"
>mv "$p" "$m"
>ln -s "${m##$D}" "$p"
>  fi
>done
>  done
>  `---
> 
>With the property that it would handle gracefully all cases were the
>maintainer has checked that no compat symlinks are required and has
>then progressively moved the pathname installation to their final
>destination under /usr.
> 
> 4) Due to having to support the broken merged-/usr-via-symlinks
>deployment, when we want to move the contents of the binary
>packages to the merged-/usr layout, we require now to include tons
>of logic in (probably new) maintainer scripts, when we have been
>trying to remove them altogether. :( With even more files untracked
>by dpkg itself, bypassing the packaging system even more, when the
>compat symlinks could have been shipped in the binary packages.
> 
> 5) Most new installations will not even benefit from this hacky and
>rushed deployment, as long as they do not use a separate parition
>for /usr!
> 
> 6) The merged-/usr-via-symlinks deployment hack is irreversible right
>now.

Just like Guillem, I'm personally not against merged-/usr but against how we
implement it. In addition to Guillems arguments, I also want to make another.

With how merged-/usr is getting deployed via debootstrap, we are placing more
of the instructions of how a Debian system is supposed to be setup *outside* of
the packages themselves (and into debootstrap). It would make a cleaner design
if we could have all necessary definitions of how to create a Debian chroot
from scratch (on a Debian system) in the packages *themselves* instead of
requiring code around the packages that is doing some magic setup (usually
debootstrap).  With mmdebstrap I am trying to write a POC to show that it is
possible to set up a Debian chroot with only very little magic and the help of
apt. My goal is to move the remaining magic setup that is currently required
into apt and dpkg (the respective maintainers are in favor of that plan but I'm
waiting for the buster release). If merged-/usr is getting implemented in the
way as it is done by debootstrap, then every debootstrap-like program has to
reproduce these mechanisms which are already architecture specific and thus not
trivial to maintain over time. It would be more elegant if the way merged-/usr
is being deployed is being encoded in the packages themselves so that we can
further *reduce* the amount of code that needs to live outside of packages
until we eventually need zero setup code before debootstrap-like programs can
install binary packages into a chroot. If we decide to deploy 

Re: Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Niko Tyni]

On Fri, Feb 22, 2019 at 11:20:24AM +0100, Didier 'OdyX' Raboud wrote:

> Thank you for the various comments. I have amended the ballot (which is more a
> "explanation text + short ballot" incorporating the suggestions from the IRC
> meeting as well as taking into accounts remarks on this bug.

Thanks for your work on this, and sorry for being so late to the party.
The summary is excellent IMO.

> * `weak`: both directory schemes are allowed, packages only built on classical
>   hosts
> * `middle`: both directory schemes are allowed, packages can be built anywhere
> * `hard`: both directory schemes are allowed, packages only built on
>   "merged `/usr`" hosts

[...]

> * B: The desireable solution at the time of bullseye is `hard`; both directory
> schemes should be allowed, and packages can be built on hosts with either
> classical or "merged-`/usr`" directory schemes.

Isn't this the 'middle' option above rather than 'hard'?

FWIW I think I'm OK with recommending 'middle' but 'hard' seems over
the top. Ideally there should be no difference in building on merged
/usr hosts vs. classical ones.


As for buster and overriding the debootstrap maintainers on the default:

I think being able to do local builds that work on other Debian
systems with minimal fuss (no chroots etc.) is a desirable property
but not an absolute requirement.  I'd certainly love to see all the
'paths_vary_due_to_usrmerge' issues fixed for buster [1].

However, given the low number of affected packages I don't think
they are a good enough reason to have the TC override the debootstrap
maintainer decision. Documenting the remaining issues with local builds
on merged-/usr hosts and aiming to eliminate them for bullseye would be
enough IMO.

[1] help on #914128 in src:perl would be welcome
-- 
Niko Tyni   nt...@debian.org

Re: Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Didier 'OdyX' Raboud]

Le lundi, 18 février 2019, 08.58:53 h CET Didier 'OdyX' Raboud a écrit :
> Dear Technical Committee members,
> (CC'ed to submitter, and debootstrap maintainers for information and
> feedack)
> 
> Here's the current state of the draft resolution; which `master` is at
> https://salsa.debian.org/debian/tech-ctte/blob/master/914897_merged_usr/ball
> ot.md
> 
> I will submit it to vote on Friday 22.; the discussion period is open!

Thank you for the various comments. I have amended the ballot (which is more a
"explanation text + short ballot" incorporating the suggestions from the IRC
meeting as well as taking into accounts remarks on this bug.

I intend to answer some mails on that bug, and call for a vote on Sunday I
guess.

See: 
https://salsa.debian.org/debian/tech-ctte/blob/master/914897_merged_usr/ballot.md
for the markdown-rendered version; and below:

# #914897: tech-ctte: Should debootstrap disable merged `/usr` by default?

## What is "merged `/usr`"

"Merged `/usr`" describes a possible future standard directories scheme in
which the `/{bin,sbin,lib*}/` directories have been made superfluous through
replacing them by symlinks to their `/usr` equivalents
(`/usr/{bin,sbin,lib*}`).
The motivation to get Debian systems to converge towards such a scheme is
vastly documented elsewhere ([FDO's TheCaseForTheUsrMerge][0],
[wiki.d.o UsrMerge][1]) but can be summarized as the following points:

* having separate `/` and `/usr` filesystems has been useful in the past for
booting without initramfs onto a minimal root filesystem that carried just
enough to mount the `/usr` filesystem later in the boot process. Given the
evolution of physical hosts' capabilities, initramfs'es have been default in
Debian (and elsewhere) for a long time, and most systems no longer have an
intermediate state during boot in which they have only `/`, but not `/usr`,
mounted. Booting hosts through that intermediate state is not systematically
tested in Debian anymore.
* another use-case is to share system files from `/usr` between hosts (over a
network link) or containers (locally) which use different data or
configuration. Having all software under `/usr` (instead of spread between `/`
and `/usr`) makes the centralized update and the sharing easier.
* the packaging infrastructure to install files outside of `/usr` (e.g.
installing libs under `/lib` instead of `/usr/lib`) is not standard and
represents technical debt.
* given its status as remnant "folklore", the distinction between what _needs_
to be shipped in `/` and what can stay in `/usr` is often interpreted
arbitrarily;
* allowing shipment of identically-named libraries or binaries in different
paths can confuse common understanding of paths precedence.

[0]: https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
[1]: https://wiki.debian.org/UsrMerge

The arguments against moving the base directories' scheme towards
"merged `/usr`" are as follows:

* there's no gain in disrupting something that is not inherently broken;
* `/{bin,sbin,lib*}/` → `/usr/{bin,sbin,lib*}/` symlinks create confusing
views of the system (`/bin/cat` and `/usr/bin/cat` are the same file), and
dpkg doesn't support this situation cleanly:
[#134758](https://bugs.debian.org/134758).
* it is possible for distributions to converge towards having all system files
in `/usr` in finite time instead of shortcutting this migration with
`/{bin,sbin,lib*}/` → `/usr/{bin,sbin,lib*}/` symlinks.

The compatibility symbolic links `/lib` → `/usr/lib` and `/lib64` →
`/usr/lib64` are required by the various CPUs' platform ABIs (for example i386
requires `/lib/ld-linux.so.2` to resolve to glibc's `ld.so`, and amd64
requires `/lib64/ld-linux-x86-64.so.2`) so there are no plans to remove them
altogether. Similarly, removing `/bin` is not under consideration because it
would break the assumption that `/bin/sh` exists, and removing `/sbin` would
break the assumption that `/sbin/fsck.*` and `/sbin/mount.*` exist.

## "merged `/usr`" in Debian

In Debian buster, the current testing suite, "merged `/usr`" is only
considered for implementation with symlinks (there are no proposals for simply
dropping `/{bin,sbin,lib*}`) and is implemented in two main ways:

* existing hosts can be made to have a "merged `/usr`" by installing the
[usrmerge][2] package;
* new hosts get the `/{bin,sbin,lib*}/`→ `/usr/{bin,sbin,lib*}/` symlinks by
default when using debootstrap >= 1.0.102.

The usrmerge package contains a `/usr/lib/convert-usrmerge` perl executable
that runs in `postinst`, that will move the contents of `/{bin,sbin,lib*}/`
and replace these directories with symlinks when empty.

It is also possible to merge `/usr` in other ways, for example with
`debootstrap --merged-usr` or by bootstrapping into a chroot that already
contains the necessary symlinks.

[2]: https://tracker.debian.org/pkg/usrmerge

## Issues from "merged `/usr`"

Since the default change in debootstrap 1.0.102, some issues have arisen.
Due to the fact that 

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Ian Jackson]

Steve McIntyre writes ("Bug#914897: tech-ctte: Should debootstrap disable 
merged /usr by default?"):
> There is a deeper worry about builds that may be done against the
> "weak" background. Although buildd chroots are easily fixed up,
> there's going to be a (small, but unknown) set of maintainers who
> might be uploading binaries from merged systems. I think we're making
> good progress on source-only uploads and building in clean chroots
> etc., but...  It's also likely not easy to pick up on "wrong" binary
> packages built this way.

I think this is a valid concern but puts it far too narrowly.


There is a persistent misunderstanding embodied in your comments here
(or rather, embodied in a significant omission): the notion that the
only reason to build a package on a Debian system is for upload to
Debian.

Once I put it like that, this notion is obviously false.  What is
happening is that the conversation is focusing on our own needs,
within Debian to help us produce Debian, to the exclusion of the needs
of our users.  That is a natural tendency of course, but we must
resist it.


Back in the wider world, of course many people build packages on
Debian systems for installation `somewhere else'.  I have done it
myself and probably many of the people reading this message have too.

What is implicitly going on here is that it is mostly-tacitly[2] being
assumed (or declared) that `I built this .deb on my laptop[1] and gave
it to my friend' is wrongheaded.

I don't think doing that is wrongheaded.  Certainly it is extremely
common; we don't have any public pronouncements saying it is somehow
wrong; and we have had little discussion where we as a project decided
that this was now a use case which we feel free to just break.


Personally I think that this is a very important thing to keep
working.  It is the very core of users' collective software freedom.

And that software freedom needs to be easy to exercise in practice.
Despite a lot of excellent tooling, chroots are still not entirely
trivial to set up and maintain.

I would invite the TC to read this manpage, which is trying to explain
to a Debian user how to change the programs on their own computer
  https://manpages.debian.org/stretch-backports/dgit/dgit-user.7.en.html
and then consider how much even worse it would be if we had to write
about chroots too.


To TC members who are minded to uphold the current approach, I would
ask: can you please explicitly state your opinion on this ?  That is:

  Is it OK for a Debian user to build .deb on their laptop and give it
  to their friend ?  If it is OK, how will we make sure that it does
  not pointlessly break ?


I readily admit that there are many ways that this can produce a
result significantly different to the official Debian package,
particularly because the package build system may configure itself
differently in the the presence of unexpected.  The resulting package
is probably not going to be suitable for wide distribution.

But those kind of problems are (a) not serious in practice
(b) generally have obvious symptoms and (c) are easily worked around
by various means.  Working around a usrmerge-generated failure is
difficult; it usually involves doing serious violence to the upstream
build system, or perhaps horrific rules file bodges.


Thanks,
Ian.


[1] Implicitly, without using a chroot.
[2] IIRC some people suggested this explicitly in the thread in
d-devel.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Ansgar]

Steve McIntyre writes:
> There is a deeper worry about builds that may be done against the
> "weak" background. Although buildd chroots are easily fixed up,
> there's going to be a (small, but unknown) set of maintainers who
> might be uploading binaries from merged systems. I think we're making
> good progress on source-only uploads and building in clean chroots
> etc., but...  It's also likely not easy to pick up on "wrong" binary
> packages built this way.

That is not a new problem: maintainers can already upload packages that
refer to binaries in /usr/local/bin when they have locally installed
binaries and autodetection using $PATH is used?  /usr/local/bin is
usually before /usr/bin and /bin after all.

dpkg could add a "not-built-in-a-clean-chroot" flag to detect those.

Ansgar

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Marco d'Itri]

On Feb 18, Didier 'OdyX' Raboud  wrote:

> * another use-case is to be able to share an identical `/usr` over a network
>   link; hence booting an initramfs, mounting a local `/`, then mounting `/usr`
>   over the network. It seems that an initramfs with everything needed to mount
>   a filesystem over a network link directly actually has a smaller footprint.
A MAJOR use case is to share /usr among different containers so that 
they use the same software (which then can be updated centrally) but 
different data and configurations.
It is a longer term goal of some projects to support booting new 
a system with empty /etc and /var directories, i.e. basically an empty 
/ partition and software coming from the (possibly read only, possibly 
snapshotted, etc) /usr partition.

> * booting with `/` only is not systematically tested in Debian anymore;
Nowadays this will surely to not work at all, at least in a default 
install. E.g. libkmod2 is in /usr/lib/.
I think that it can be safely said that Debian does not support booting 
systems with a standalone /usr/ and no initramfs.

> In Debian buster, the current testing suite, "merged `/usr`" is only 
> considered
> for implementation with symlinks (there are no proposals for simply dropping
> `/{bin,sbin,lib*}`) and is implemented in two main ways:
For clarity: I am not aware of anybody anywhere proposing to drop the 
/{bin,sbin,lib*} links, for Debian or any other distribution.

Thank you for this excellent summary.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Steve McIntyre]

Hi Didier,

While I'm not necessarily disagreeing with the overall point(s) here,
some of the points in this list of arguments seem dubious at
best. Maybe you could expand?

>* having separate `/` and `/usr` filesystems has been useful in the past for
>  booting without initramfs onto a minimal root filesystem that carried just
>  enough to mount the `/usr` filesystem later in the boot process. Given the
>  evolution of physical hosts' capabilities, initramfs'es have been default in
>  Debian (and elsewhere) for a long time, and most systems no longer have an
>  intermediate state during boot in which they have only `/`, but not `/usr`,
>  mounted.
>* another use-case is to be able to share an identical `/usr` over a network
>  link; hence booting an initramfs, mounting a local `/`, then mounting `/usr`
>  over the network. It seems that an initramfs with everything needed to mount
>  a filesystem over a network link directly actually has a smaller footprint.
>* booting with `/` only is not systematically tested in Debian anymore;

I'm assuming you mean "/ without /usr" here?

>* the packaging infrastructure to install files outside of `/usr` is not
>  standard and represents technical debt:

I have no idea what you're suggesting here.

>* given its status as remnant "folklore", the distinction between what _needs_
>  to be shipped in `/` and what can stay in `/usr` is often interpreted
>  arbitrarily;
>* allowing shipment of identically-named libraries or binaries in different
>  paths can confuse common understanding of paths precedence.

...

>Various valid long-term desireable situations coexist, and while discussing
>immediate countermeasures, it is useful to keep the long-term outcome that
>those are most likely to produce.
>
>These are the five possible situations at the time of bullseye (buster + 1):
>
>* `none`: "merged `/usr`" has been reverted
>* `weak`: both directory schemes are allowed, packages only built on classical
>  hosts
>* `middle`: both directory schemes are allowed, packages can be built anywhere
>* `hard`: both directory schemes are allowed, packages only built on
>  "merged `/usr`" hosts
>* `all`: only "merged `/usr`" directory schemes are allowed, packages only
>  built on "merged `/usr`" hosts
>
>It can be summarized by the following table:
>
>```
>|  | Host types that are allowed   | Are merged `/usr` | 
>Official packages are built on| Packages built on … can break on the other 
>|
>| Codename | classical hosts | merged `/usr` hosts | symlinks allowed  | 
>classical hosts | merged `/usr` hosts |   classical hosts   |  merged `/usr` 
>hosts |
>|--|-|-|---|—|-|-|--|
>| none |   yes   |  no | no|   
>yes   |  no | yes |  yes |
>| weak |   yes   | yes |yes|   
>yes   |  no |  no |  yes |
>|   middle |   yes   | yes |yes|   
>yes   | yes |  no |   no |
>| hard |   yes   | yes |yes|   
> no   | yes |  no |   no |
>|  all |   no| yes |yes|   
> no   | yes | yes |   no |
>```
>
>The current state of buster is `weak`.
>
>=== DRAFT Resolution ===
>
>The Technical Committee resolves to:
>
>* Option A: Ask the debootstrap maintainers to disable "merged `/usr`" by
>  default
>  (Using its §6.1.4 "Overrule a Developer" power; requires a 3:1 majority)
>
>  Given that:
>  * hosts with both directory schemes already exist,
>  * the "merged `/usr`" directory scheme ought to be reserved for special
>use-cases,
>  * official packages ought to only be built on classical directory schemes,
>
>  … the Technical Committee considers that the desireable solution at the time
>  of bullseye is `weak`; and asks the debootstrap maintainers to disable
>  "merged `/usr`" by default.

There is a deeper worry about builds that may be done against the
"weak" background. Although buildd chroots are easily fixed up,
there's going to be a (small, but unknown) set of maintainers who
might be uploading binaries from merged systems. I think we're making
good progress on source-only uploads and building in clean chroots
etc., but...  It's also likely not easy to pick up on "wrong" binary
packages built this way.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
The two hard things in computing:
 * naming things
 * cache invalidation
 * off-by-one errors  -- Stig Sandbeck Mathisen

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Cyril Brulebois]

Hi,

Didier 'OdyX' Raboud  (2019-02-18):
> Dear Technical Committee members,
> (CC'ed to submitter, and debootstrap maintainers for information and feedack)
> 
> Here's the current state of the draft resolution; which `master` is at
> https://salsa.debian.org/debian/tech-ctte/blob/master/914897_merged_usr/ballot.md

Thanks, Didier.

While I haven't dived into it as deep as you did (e.g. I didn't proofread
the big table at the end), that seems like a reasonable characterization
of the current situation; many thanks for your highly detailed summary.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Didier 'OdyX' Raboud]

Dear Technical Committee members,
(CC'ed to submitter, and debootstrap maintainers for information and feedack)

Here's the current state of the draft resolution; which `master` is at
https://salsa.debian.org/debian/tech-ctte/blob/master/914897_merged_usr/ballot.md

I will submit it to vote on Friday 22.; the discussion period is open!

# #914897: tech-ctte: Should debootstrap disable merged `/usr` by default?

## What is "merged `/usr`"

"Merged `/usr`" describes a possible future standard directories scheme in
which the `/{bin,sbin,lib*}/` directories have been made superfluous through
replacing them by symlinks to their `/usr` equivalents (/usr/{bin,sbin,lib*}).
The motivation to get Debian systems to converge towards such a scheme is
vastly documented elsewhere ([FDO's TheCaseForTheUsrMerge][0],
[wiki.d.o UsrMerge][1]) but can be summarized as the following points:

* having separate `/` and `/usr` filesystems has been useful in the past for
  booting without initramfs onto a minimal root filesystem that carried just
  enough to mount the `/usr` filesystem later in the boot process. Given the
  evolution of physical hosts' capabilities, initramfs'es have been default in
  Debian (and elsewhere) for a long time, and most systems no longer have an
  intermediate state during boot in which they have only `/`, but not `/usr`,
  mounted.
* another use-case is to be able to share an identical `/usr` over a network
  link; hence booting an initramfs, mounting a local `/`, then mounting `/usr`
  over the network. It seems that an initramfs with everything needed to mount
  a filesystem over a network link directly actually has a smaller footprint.
* booting with `/` only is not systematically tested in Debian anymore;
* the packaging infrastructure to install files outside of `/usr` is not
  standard and represents technical debt:
* given its status as remnant "folklore", the distinction between what _needs_
  to be shipped in `/` and what can stay in `/usr` is often interpreted
  arbitrarily;
* allowing shipment of identically-named libraries or binaries in different
  paths can confuse common understanding of paths precedence.

The arguments against moving the base directories' scheme towards
"merged `/usr`" are as follows:

* there's no gain in disrupting something that is not inherently broken;
* `/{bin,sbin,lib*}/` → `/usr/{bin,sbin,lib*}/` symlinks create confusing views
  of the system (`/bin/cat` and `/usr/bin/cat` are the same file), and dpkg
  doesn't support this situation cleanly
  [#134758](https://bugs.debian.org/134758).

[0]: https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
[1]: https://wiki.debian.org/UsrMerge

The compatibility symbolic links `/lib` → `/usr/lib` and
`/lib64` → `/usr/lib64` are required by the various CPUs' platform ABIs (for
example i386 requires `/lib/ld-linux.so.2` to resolve to glibc's `ld.so`, and
amd64 requires `/lib64/ld-linux-x86-64.so.2`) so there are no plans to remove
them altogether. Similarly, removing `/bin` is not under consideration because
it would break the assumption that `/bin/sh` exists, and removing `/sbin` would
break the assumption that `/sbin/fsck.*` and `/sbin/mount.*` exist.

## "merged `/usr`" in Debian

In Debian buster, the current testing suite, "merged `/usr`" is only considered
for implementation with symlinks (there are no proposals for simply dropping
`/{bin,sbin,lib*}`) and is implemented in two main ways:

* existing hosts can be made to have a "merged `/usr`" by installing the
  [usrmerge][2] package;
* new hosts get the `/{bin,sbin,lib*}/`→ `/usr/{bin,sbin,lib*}/` symlinks by
  default when using debootstrap >= 1.0.102.

The usrmerge package contains a `/usr/lib/convert-usrmerge` perl executable
that runs in `postinst`, that will move the contents of `/{bin,sbin,lib*}/` and
replace these directories with symlinks when empty.

It is also possible to merge `/usr` in other ways, for example with
`debootstrap --merged-usr` or by bootstrapping into a chroot that already
contains the necessary symlinks.

[2]: https://tracker.debian.org/pkg/usrmerge

## Issues from "merged `/usr`"

Since the default change in debootstrap 1.0.102, some issues have arisen.
Due to the fact that some buster/sid hosts have the "merged `/usr`" symlinks in
place, it has been observed that some binary packages carried some traces of
these differences (notably official packages built on Debian buildd hosts which
had been resetup).
Some such differences can actually render the built packages unuseable on
non-"merged `/usr`" systems.
For example, if `cat` is detected at build-time in `/usr/bin/cat` (where
coreutils ships `/bin/cat`), a binary hardcoding that path will try to use
`/usr/bin/cat` after installation, but that path doesn't exist in
non-"merged `/usr`" systems.
In order to mitigate this, debootstrap has been modified to let its "buildd"
variant be non-"merged `/usr`", the Debian buildds have been resetup and the
affected packages 

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Gunnar Wolf]

Didier 'OdyX' Raboud dijo [Sat, Feb 02, 2019 at 03:38:01PM +0100]:
> Le samedi, 2 février 2019, 14.48:22 h CET Ian Jackson a écrit :
> > Ping ?
> 
> Thank for the ping.
> 
> Gunnar and myself have started working on a draft, the latest version of 
> which 
> is available at
> 
>   https://salsa.debian.org/debian/tech-ctte/blob/master/914897_merged_usr/
> ballot.md

FWIW, crediting me at the same level as you is a gross overstatement
of my lone commit fixing minimal changes. It is clearly your work -
And all of the consecutive edits (which I completely support) add to this.

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Ansgar]

Ian Jackson writes:
> This is especially the case since none of the other possible
> candidates for how to set this distribution-wide policy are useable:
> the Policy editors have decided that Policy should lag implementation
> rather than lead it; debian-devel didn't work; and there is no other
> forum or body with sufficient breadth.

I was asked for a discussion on -devel@ by the d-i maintainers before I
filed the bug report to enable this feature.  It is mentioned in the
initial bug report too[1].

  [1] https://bugs.debian.org/839046#5

While you claimed[2] there were negative responses in that particular
thread, there weren't any as far as I could see[3].  Sadly you didn't
bother replying.

  [2] https://bugs.debian.org/839046#94
  [3] https://bugs.debian.org/839046#112

You didn't provide any concrete examples of what would be broken back
then, even when explicitly asked[4].

  [4] https://bugs.debian.org/839046#99

The same pattern seems to continue as you claimed that the "design is
broken" in the request to the ctte[5], but do not want to provide
reasoning why.  Or make claims that there wasn't enough consultation
(even though there was so much discussion that LWN wrote at least one
article about the discussion on -evel@); as usual you do not follow-up
on requests to clarify any of this.

  [5] https://bugs.debian.org/914897#208

(Not that having consensus would mean anything given how you handle that
in [6]...)

  [6] https://bugs.debian.org/850967#42

I'm sorry, but I feel that you are not interested in discussions around
technical problems, but instead (once again) fight for some other reason
(just like in the DUNE bug IMHO)...  The (solvable and minor) technical
problem that was reported half a year after the default was switched was
just a convenient starting point to escalate the issue; it isn't even
mentioned any more: instead you now switch to "social costs".

Here I find it unfair to pressure people into reverting the change /now/
as the freeze comes closer as such reasons would have applied the years
before November as well, and certainly since the default was switched
again in June last year.

Ansgar

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Ian Jackson]

David Bremner writes ("Re: Bug#914897: tech-ctte: Should debootstrap disable 
merged /usr by default?"):
> There is a draft ballot being prepared for a vote. I'm not sure when
> that will be ready.  The minutes of the last TC meeting should have more
> precise information than my memory.

Thanks.

I just read the discussion in the irc log.

I theme I identified in it was the social cost of overriding the
debootstrap maintainer.

A contrasting issue that was not really discussed is the social cost
of allowing the debootstrap maintainers to impose this transition on
the rest of the project.

(This is difficult to disconnect from the unpleasant communication
style of one of the principal usrmerge advocates on debian-devel.)


Also, I think whether Debian installs should have merged /usr by
default is a matter of technical policy which the TC ought to feel
free to address directly.

This is especially the case since none of the other possible
candidates for how to set this distribution-wide policy are useable:
the Policy editors have decided that Policy should lag implementation
rather than lead it; debian-devel didn't work; and there is no other
forum or body with sufficient breadth.

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Didier 'OdyX' Raboud]

Le samedi, 2 février 2019, 14.48:22 h CET Ian Jackson a écrit :
> Ping ?

Thank for the ping.

Gunnar and myself have started working on a draft, the latest version of which 
is available at

https://salsa.debian.org/debian/tech-ctte/blob/master/914897_merged_usr/
ballot.md

It's really work-in-progress, and hasn't had much scrutiny yet (hence why I'm 
not pasting it here).  I've started working on the various long-term 
desireable situations, but have realized I need to draw a table to wrap my 
head around this.

I hope to get it done during Monday (FOSDEM is not the ideal space+time to get 
the needed calm to think about these complex issues).

Cheers,
OdyX

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[David Bremner]

Ian Jackson  writes:

> Ping ?
>
> Is the TC engaged in this issue or should I seek another approach ?
>
> Ian.

There is a draft ballot being prepared for a vote. I'm not sure when
that will be ready.  The minutes of the last TC meeting should have more
precise information than my memory.

d

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Ian Jackson]

Ping ?

Is the TC engaged in this issue or should I seek another approach ?

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Cyril Brulebois]

Hi,

Simon McVittie  (2018-12-23):
> To be completely clear about the decision that Ian asked the technical
> committee to overrule:
> 
> In all debootstrap versions since 1.0.102, merged /usr is the default
> (for all variants except --variant=buildd). This means that new
> installations of Debian buster using debian-installer will have merged
> /usr.
> 
> Do the debian-installer and debootstrap maintainers think this should
> continue to be true for the buster release?

As might have been noticed, I haven't been following Debian topics very
closely lately, but on this specific topic: I'm not aware of blockers
that should prevent us from keeping this new default setting.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Hideki Yamane]

Hi,

On Sun, 23 Dec 2018 00:36:52 +
Simon McVittie  wrote:
> To be completely clear about the decision that Ian asked the technical
> committee to overrule:
> 
> In all debootstrap versions since 1.0.102, merged /usr is the default (for
> all variants except --variant=buildd). This means that new installations
> of Debian buster using debian-installer will have merged /usr.
> 
> Do the debian-installer and debootstrap maintainers think this should
> continue to be true for the buster release?

 At this time, yes. +1

 However, if it'll be a blocker for release during freeze, it should
 be reverted.


-- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Marco d'Itri]

On Dec 23, Simon McVittie  wrote:

> An alternative to the usrmerge package might be to do this transition
> in an initramfs hook or something similar, which would guarantee that
> nothing else is concurrently altering /usr or the directories that are
> meant to be merged into it.
FWIW I tried implementing that in 
https://salsa.debian.org/md/usrmerge/tree/initramfs, but it does not 
work because I was not able to open an interactive shell from the 
initramfs script.
Some help from people familiar with initramfs-tools would be 
appreciated.

BTW, that branch also contains a simple script which can be used to 
run the current system in KVM with a throwaway snapshot, to be able to 
try usrmerge with no consequences.

> This remains true even if the usrmerge package is subsequently removed,
> if it was ever installed. The symlinks /bin, /sbin, /lib* remain present,
A clarification: usrmerge is supposed to be removed after the conversion.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Simon McVittie]

To be completely clear about the decision that Ian asked the technical
committee to overrule:

In all debootstrap versions since 1.0.102, merged /usr is the default (for
all variants except --variant=buildd). This means that new installations
of Debian buster using debian-installer will have merged /usr.

Do the debian-installer and debootstrap maintainers think this should
continue to be true for the buster release?

(Sorry, I should have made this the only question in a message, and not
mentioned side issues in the same message.)

Thanks,
smcv

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default?

[Simon McVittie]

On Wed, 05 Dec 2018 at 14:03:19 +0100, Svante Signell wrote:
> How about this case:
> 
> - Make as default non merged-/usr for all buildds.

This has been done: I sent patches, which have been applied.
(This is actually implemented in two different places, either of which
would have been sufficient to make this happen on all official buildds:
the Debian sysadmins' script to refresh sbuild chroots explicitly
requests unmerged /usr, and debootstrap --variant=buildd also defaults
to unmerged /usr.)

> - Make a choice of non merged-/usr or merged-/usr in the installer.

If you mean "the installer maintainers make a choice": this is effectively
what we have now. The debian-installer maintainers are the maintainers
of debootstrap, they have chosen to merge /usr in new installations,
and this bug report is a request for the technical committee to decide
whether to overrule them.

If you mean "users who run the installer are asked whether they want
merged or unmerged /usr": this seems worse than either merged /usr or
unmerged /usr, because it's asking new Debian users to make a choice in
which they likely have no way to know which answer is most appropriate,
because they aren't using Debian yet. If even experienced Debian users
disagree over what the answer should be (which we do, as you can see in
this thread), then we should not expect new users to be able to make
an informed decision.

> - Users wanting merged-/usr install the usrmerge package and convert to 
> merged-
> /usr.

This is one of several ways to achieve that result: either install
usrmerge, or install into a sysroot that already contains symlinks
/lib -> /usr/lib etc., or use debootstrap --merged-usr (or a recent
debootstrap version in which merged /usr is the default for recent
suites), or do the equivalent of usrmerge by hand.

Merging /usr on an existing system isn't actually difficult to implement
if you are manipulating the system from the outside: the hard parts of
the task of the usrmerge package are making it work on a running system,
and avoiding the system being left in a broken state if the transition
to merged /usr is left half-complete.

An alternative to the usrmerge package might be to do this transition
in an initramfs hook or something similar, which would guarantee that
nothing else is concurrently altering /usr or the directories that are
meant to be merged into it.

> 2) For those having merged-/usr installed:
>Re-run usrmerge to convert all newly installed packages to merged-/usr.
>Is this possible or is installing that package a install-once-only?

If you already have the merged-/usr filesystem layout (either by
installing usrmerge, by using debootstrap with --merged-usr, or by
creating the symlinks some other way), then all newly installed packages
effectively already behave as though they had been converted to merged
/usr: dpkg sees that the .deb contains a file like /bin/sed, but the
root filesystem contains a symlink /bin -> /usr/bin, so it dereferences
the symlink and unpacks sed into /usr/bin. This is part of dpkg's more
general support for relocating directories elsewhere by replacing them
with a symlink.

If that wasn't true, then the usrmerge package would not have been
feasible to implement. It would clearly have been unacceptable to make it
impossible to install unmodified packages later.

This remains true even if the usrmerge package is subsequently removed,
if it was ever installed. The symlinks /bin, /sbin, /lib* remain present,
because removing them would break the system: paths like /bin/sh,
/sbin/fsck, /lib/ld-linux.so.2 and /lib64/ld-linux-x86-64.so.2 must
continue to work indefinitely (even if the files are physically located
at /usr/bin/sh, /usr/sbin/fsck and so on).

smcv

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default? /usr by default

[Hideki Yamane]

Hi,

On Wed, 5 Dec 2018 08:39:27 +
Simon McVittie  wrote:
> It might also be considered appropriate to revert the change in
> debootstrap 1.0.111 if data from reproducible-builds demonstrates that
> bugs similar to #913226 have all been fixed or are very rare, but this
> should be done cautiously, and certainly not before buster is released.

 Okay, my opinion is "Push usr-merge effort forward, fix those issues
 with it as bug that is tracked at reproducible builds(*), and turn it
 on again as default (probably after buster cycle)".

 *) 
https://tests.reproducible-builds.org/debian/issues/unstable/paths_vary_due_to_usrmerge_issue.html


-- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp

Processed: Re: Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default? /usr by default

[Debian Bug Tracking System]

Processing control commands:

> retitle 914897 tech-ctte: Should debootstrap disable merged /usr by default?
Bug #914897 [tech-ctte] debootstrap, buster: Please disabled merged /usr by 
default
Changed Bug title to 'tech-ctte: Should debootstrap disable merged /usr by 
default?' from 'debootstrap, buster: Please disabled merged /usr by default'.

-- 
914897: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914897
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#914897: tech-ctte: Should debootstrap disable merged /usr by default? /usr by default

[Simon McVittie]

Control: retitle 914897 tech-ctte: Should debootstrap disable merged /usr by 
default?

I'm retitling the bug to avoid misrepresenting the technical committee's
position on this. We have been asked to overrule the debootstrap
maintainer, but we have not yet come to a conclusion on whether we should.

On Wed, 05 Dec 2018 at 13:25:36 +0900, Hideki Yamane wrote:
>  Can we check and track this behavior in our packages?

Yes, we now do. The reproducible-builds infrastructure now uses unmerged
/usr for the first build and merged /usr for the second, since
 was fixed.

debootstrap since 1.0.111 also mitigates this class of bugs by disabling
merged /usr for --variant=buildd chroots (this was
).

Julien Cristau thinks #914208 was a sufficient/proportionate change, and
doesn't want to go further and default to --no-merged-usr for non-buildd
chroots (and in particular new debian-installer installations).

Ian Jackson thinks #914208 is not a sufficient answer (Ian, I hope I'm
not misrepresenting you here?), and escalated this bug to the technical
committee, asking us to overrule the debootstrap maintainers.

If the debootstrap/debian-installer maintainers agree with Ian on this,
then there is no need for the technical committee to consider his request
to overrule you, which is why Didier asked for your opinion on this
issue before attempting to come to a decision. If you agree with Julien,
then the technical committee still needs to consider this question.

>  Once disable merged-usr is good to prevent confusion but we detect such
>  as a bug for manage non-merged-usr and merged-usr Debian system in the end,
>  right? (or do you want to stay change in debootstrap 1.0.111 forever?)

The technical committee have not come to a conclusion on this.

My personal opinions (not overruling anyone):

If merged /usr becomes the only supported system layout at some future
time, then the change in debootstrap 1.0.111 can certainly be reverted
at that time. (If merged /usr does not become the only supported system
layout, this does not apply.)

It might also be considered appropriate to revert the change in
debootstrap 1.0.111 if data from reproducible-builds demonstrates that
bugs similar to #913226 have all been fixed or are very rare, but this
should be done cautiously, and certainly not before buster is released.

smcv