[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



On Tue, 2022-08-16 at 21:06 +0100, Luca Boccassi wrote:
> On Thu, 2022-07-28 at 13:14 +0100, Luca Boccassi wrote:
> > On Sun, 2022-07-17 at 00:56 +0100, Luca Boccassi wrote:
> > > On Mon, 2021-10-18 at 12:17 -0700, Sean Whitton wrote:
> > > > Hello,
> > > > 
> > > > On Wed 15 Sep 2021 at 11:46AM +01, Simon McVittie wrote:
> > > > 
> > > > > 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.
> > > > 
> > > > With five votes cast in favour of the text by Simon, Niko,
> > > > Gunnar,
> > > > Marga
> > > > and myself, the outcome is no longer in doubt.  Thus, in
> > > > accordance
> > > > with
> > > > the Debian Constitution, the voting period has now concluded.
> > > > 
> > > > Therefore, using its powers under section 6.1.5 of the Debian
> > > > Constitution, the Technical Committee issues the following
> > > > advice:
> > > > 
> > > > 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 that will lead to Debian 12, and
> > > > subsequently
> > > >   upgrading from testing/unstable to Debian 12 (stable release)
> > > > 
> > > > What we understand this to imply is as follows:
> > > > 
> > > > - Because Debian 11 installations with the merged-/usr layout
> > > > already
> > > >   exist, and because Debian 12 should only support the merged-
> > > > /usr
> > > >   layout, all packages in Debian 12 should be installable onto
> > > > a
> > > >   merged-/usr system along with their dependencies, and work
> > > > correctly
> > > >   on the resulting system.
> > > > 
> > > > - 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.
> > > > 
> > > >     + The key reason for this is that apt is not required to
> > > > perform
> > > > the
> > > >       upgrade between stable releases in any particular order,
> > > > so
> > > > long
> > > >       as package dependency relationships are respected;
> > > > therefore
> > > > the
> > > >       upgrade can happen in whatever order apt chooses, which
> > > > can
> > > > vary
> > > >       between machines. Debian has not traditionally required
> > > > use of
> > > > a
> > > >       special upgrade tool similar to Ubuntu's do-release-
> > > > upgrade(8)
> > > > and
> > > >       we believe the upgrade to Debian 12 should be no
> > > > different (see
> > > >       below for more details on this topic).
> > > > 
> > > >     + Another reason for this is that during the development of
> > > > Debian
> > > >       12, testing/unstable systems undergo a series of partial
> > > > upgrades,
> > > >       which similarly will happen in an undefined order.
> > > > 
> > > >     + We do not require that the resulting system remains
> > > >       non-merged-/usr: if the packages involved in this
> > > > installation
> > > >       transaction are part of the implementation of a
> > > > transition to
> > > >       merged-/usr, then installing them might result in the
> > > > system
> > > >       becoming merged-/usr.
> > > > 
> > > > - The same expectations apply to packages uploaded to
> > > > testing/unstable
> > > >   during the development cycle that will lead to Debian 12.
> > > > 
> > > > - Debian contributors who are interested in merged-/usr are
> > > > invited
> > > > to
> > > >   implement a straightforward migration path from non-merged-
> > > > /usr to
> > > >   merged-/usr. The Technical Committee will not design this
> > > > migration
> > > >   path in detail. If disputes arise related to this migration
> > > > path,
> > > > or
> > > >   if advice on this migration path is requested, we will
> > > > resolve
> > > > those
> > > >   by following our usual procedures.
> > > > 
> > > >     + One example of a migration path that might be used is for
> > > > an
> > > >       Essential package to add a dependency on the usrmerge
> > > > package,
> > > > so
> > > >       that it will be installed automatically during upgrades.
> > > > We do
> > > > not
> > > >       require this to be the migration path that is chosen; it
> > > > is
> > > >       presented here merely to demonstrate that such a
> > > > migration path
> > > >       can exist.
> > > > 
> > > > - After Debian 12 is released, the transition to merged-/usr is
> > > >   considered to be complete. Because we do not support
> > > > "skipping a
> > > >   release" when upgrading systems, new packages uploaded to
> > > >   testing/unstable during the development cycle that will lead
> > > > to
> > > > Debian
> > > >   13 may assume and require that the system onto which they are
> > > >   installed is merged-/usr.
> > > > 
> > > > If a suitable transition mechanism is not available by the time
> > > > the
> > > > Debian 12 freeze is reached, the Technical Committee will
> > > > rescind our
> > > > advice in #978636 and modify our advice in this resolution to
> > > > reflect
> > > > the situation that has been reached. We hope that this will not
> > > > be
> > > > necessary.
> > > > 
> > > > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978636
> > > > 
> > > > Use of a special upgrade path
> > > > =============================
> > > > 
> > > > Some developers have argued that we should deploy merged /usr
> > > > by
> > > > means
> > > > of a special upgrade path, with all other upgrade paths being
> > > > declared
> > > > to be unsupported. Some examples of special upgrade paths that
> > > > might
> > > > be
> > > > proposed:
> > > > 
> > > > - upgrading dpkg before carrying out the rest of the upgrade
> > > > 
> > > > - installing the usrmerge package before carrying out the
> > > > upgrade
> > > > 
> > > > - using a special tool similar to Ubuntu's do-release-
> > > > upgrade(8)
> > > > which
> > > >   encapsulates whatever steps are necessary
> > > > 
> > > > This would imply that upgrade paths other than the recommended
> > > > one
> > > > are
> > > > not expected to work.
> > > > 
> > > > We are aware that many Debian users do not read the release
> > > > notes
> > > > before
> > > > upgrading from oldstable to stable, and will expect to be able
> > > > to
> > > > upgrade via whatever apt commands they are used to using,
> > > > regardless
> > > > of
> > > > whether the release notes recommend something different. Given
> > > > that
> > > > there are alternatives available, we do not think that merged-
> > > > /usr is
> > > > sufficiently good cause to interfere with this.
> > > > 
> > > > During the Debian 12 development cycle, users of
> > > > testing/unstable
> > > > will
> > > > also need an upgrade path from Debian 11 to testing/unstable,
> > > > or from
> > > > older to newer snapshots of testing/unstable. In general this
> > > > will be
> > > > done using apt, and it needs to continue to work if at all
> > > > possible,
> > > > even before a special upgrade tool has been prepared;
> > > > introducing a
> > > > "flag day" at which all testing/unstable users are expected to
> > > > carry
> > > > out
> > > > additional non-automatic upgrade steps would be disruptive, and
> > > > in
> > > > practice many testing/unstable users are likely to skip those
> > > > steps.
> > > > 
> > > > For these reasons, we make the simple, conservative
> > > > recommendation
> > > > that
> > > > a special upgrade path should not be required, and upgrading
> > > > via apt
> > > > in
> > > > approximately the same way as previous Debian releases should
> > > > continue
> > > > to work in general.
> > > > 
> > > > Testing and QA
> > > > ==============
> > > > 
> > > > We anticipate that during the development cycle that will lead
> > > > to
> > > > Debian
> > > > 12, it is likely to be useful for testing and QA infrastructure
> > > > (such
> > > > as
> > > > autopkgtest, piuparts and/or reproducible-builds) to be able to
> > > > produce
> > > > an installation of Debian testing/unstable that is not merged-
> > > > /usr,
> > > > in
> > > > order to be able to verify that packages targeted for inclusion
> > > > in
> > > > Debian 12 can still be installed and/or built successfully in a
> > > > non-merged-/usr environment during partial upgrades.
> > > > 
> > > > As a result, we recommend that if there is an automatic
> > > > migration
> > > > from
> > > > non-merged-/usr to merged-/usr, it should be possible to
> > > > prevent that
> > > > migration. However, systems where that migration has been
> > > > prevented
> > > > are
> > > > not required to be fully-supported, and in particular,
> > > > upgrading them
> > > > to
> > > > Debian 13 or to the state of testing/unstable during
> > > > development of
> > > > Debian 13 should be considered unsupported.
> > > > 
> > > > Building packages
> > > > =================
> > > > 
> > > > In #914897 [3] the Technical Committee resolved that for Debian
> > > > 11,
> > > > packages can validly be built in either a merged-/usr or non-
> > > > merged-
> > > > /usr
> > > > environment.  We understand this to imply that packages built
> > > > in
> > > > either
> > > > a merged-/usr or non-merged-/usr environment should work as
> > > > intended
> > > > in
> > > > either a merged-/usr or non-merged-/usr environment.
> > > > 
> > > > There is a class of bugs in which a package embeds the absolute
> > > > path
> > > > to
> > > > some executable or other file, in such a way that if it is
> > > > built in
> > > > an
> > > > environment with a unified /usr (either via merged-/usr or
> > > > symlink
> > > > farms), this can result in embedding a non-canonical path such
> > > > as
> > > > /usr/bin/sh or /bin/env which will not work correctly in a
> > > > non-merged-/usr environment.  The Technical Committee reminds
> > > > maintainers that packages in Debian 12 are expected to work
> > > > correctly
> > > > in
> > > > a non-merged-/usr environment, and therefore this class of bugs
> > > > needs
> > > > to
> > > > be resolved. As a result, we recommend that these bugs should
> > > > generally
> > > > be treated as release-critical for Debian 12 by maintainers and
> > > > the
> > > > release team.
> > > > 
> > > > The Reproducible Builds effort tracks this class of bugs as
> > > > "paths_vary_due_to_usrmerge" [4] and many bugs in this class
> > > > are
> > > > tracked
> > > > with the usertag "usrmerge" [5]. In Autotools-based build
> > > > systems,
> > > > they
> > > > can often be avoided by passing arguments such as
> > > > `SED=/bin/sed` to
> > > > the
> > > > configure script.
> > > > 
> > > > Note that although the name of the usertag mentions usrmerge,
> > > > this
> > > > class
> > > > of bugs is not specific to the usrmerge package, and not
> > > > completely
> > > > specific to merged-/usr; many of these bugs would also manifest
> > > > if
> > > > unified /usr was achieved via symlink farms, or if a local
> > > > executable
> > > > such as /usr/local/bin/sed existed on the build system.
> > > > 
> > > > #993675 [6] is a typical example of this class of bugs.
> > > > 
> > > > [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914897
> > > > [4]:
> > > > https://tests.reproducible-builds.org/debian/issues/unstable/paths_vary_due_to_usrmerge_issue.html
> > > > [5]:
> > > > https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=reproducible-builds%40lists.alioth.debian.org&tag=usrmerge
> > > > [6]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993675
> > > > 
> > > > Moratorium on moving files' logical locations into /usr
> > > > =======================================================
> > > > 
> > > > In the past, some package maintainers have taken advantage of
> > > > the
> > > > fact
> > > > that /usr is now required to be mounted during early boot
> > > > (since
> > > > Debian
> > > > 9) to move individual files from the root filesystem to /usr.
> > > > Examples
> > > > of this being done during previous development cycles include
> > > > the
> > > > libglib-2.0.so.0 and libgcrypt.so.20 shared libraries, and the
> > > > command-line utilities in the iptables package.
> > > > 
> > > > The Technical Committee recommends that during the Debian 12
> > > > development
> > > > cycle, the maintainers of individual packages should not
> > > > proactively
> > > > move files from the root filesystem to the corresponding
> > > > locations in
> > > > /usr in the data.tar.* of packages. Files that were in /usr in
> > > > the
> > > > Debian 11 release should remain in /usr, while files that were
> > > > in
> > > > /bin,
> > > > /lib* or /sbin in the Debian 11 release should remain in those
> > > > directories.  If files were moved from /bin, /lib* or /sbin
> > > > into /usr
> > > > since the Debian 11 release, they should be moved back to their
> > > > Debian
> > > > 11 locations.
> > > > 
> > > > Similarly, during the Debian 12 development cycle, we recommend
> > > > that
> > > > maintainers of tools such as debhelper should not move files
> > > > from the
> > > > root filesystem into /usr.
> > > > 
> > > > For example, debhelper 13.4 started moving systemd units from
> > > > /lib/systemd into /usr/lib/systemd, but this was subsequently
> > > > reverted
> > > > in 13.5.2. We consider the revert that was done in 13.5.2 to
> > > > have
> > > > been
> > > > an appropriate course of action.
> > > > 
> > > > We issue this recommendation for several reasons:
> > > > 
> > > > - The transition to merged-/usr will make the logical locations
> > > > of
> > > > these
> > > >   files irrelevant to their physical locations.
> > > > 
> > > > - The transitional mechanisms necessary to prevent such moves
> > > > from
> > > >   breaking other packages that hard-code specific paths are
> > > > error-
> > > > prone,
> > > >   and can themselves interfere with the transition to merged-
> > > > /usr.
> > > > 
> > > > - After the transition to merged-/usr has completed, during the
> > > > Debian
> > > >   13 development cycle, we expect that maintainers will be able
> > > > to
> > > > move
> > > >   these files without needing transitional mechanisms.
> > > > 
> > > > - 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.
> > > > 
> > > > - On non-merged-/usr systems, a failure mode has been observed
> > > > in
> > > > which
> > > >   older shared libraries in /lib/MULTIARCH are not always
> > > > deleted as
> > > >   intended, and interfere with correct loading of the newer
> > > > shared
> > > >   library in /usr/lib/MULTIARCH. 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,
> > > > at
> > > >   which point ldconfig(8) will choose the newer library even if
> > > > this
> > > >   occurs.
> > > > 
> > > > This recommendation applies until Debian 12 is released, or
> > > > until a
> > > > subsequent Technical Committee resolution rescinds it,
> > > > whichever is
> > > > sooner. We intend to rescind this recommendation if mechanisms
> > > > are
> > > > developed to avoid the undesired side-effects of moving files
> > > > from
> > > > the
> > > > root filesystem into /usr.
> > > > 
> > > > For the Technical Committee:
> > > 
> > > Hello Technical Committee members,
> > > 
> > > We are half a year from the first Bookworm freeze, and more than
> > > half a
> > > year since the quoted decision. While no progress has been made
> > > in
> > > Debian, in this period of time OpenMandrive finished their
> > > transition,
> > > and Gentoo and Yocto started planning theirs, and Ubuntu
> > > forcefully
> > > upgraded all old installations, that existed before the installer
> > > was
> > > changed, that updated to 21.10 and the LTS 22.04. The list of
> > > distributions shipping with the legacy layout is getting smaller
> > > and
> > > smaller. It is time to complete this work, before upstream
> > > software
> > > start dropping support too.
> > > 
> > > So here's the plan for Debian Bookworm, in accordance with your
> > > decision as quoted above.
> > > 
> > > Piuparts has been enhanced with a new test case that covers the
> > > moratorium on moving files manually between their location in the
> > > root
> > > directories and /usr. This also covers moves between packages,
> > > and
> > > across a distribution upgrade. I am told this test is now live
> > > and thus
> > > covering all packages migrating from unstable to testing [0].
> > > This coverage will give us peace of mind that the hypothetical
> > > and
> > > never-seen failure modes described in your decision cannot happen
> > > unnoticed, will be caught by Piuparts and cause the package to
> > > become
> > > RC-buggy.
> > > 
> > > The usrmerge package has been updated to pick up a few fixes from
> > > Ubuntu, and most importantly to provide a new lightweight
> > > metapackage,
> > > usr-is-merged, that can only be installed on merged-usr systems,
> > > to
> > > provide a way for installers to avoid the additional dependencies
> > > of
> > > usrmerge when they set up the filesystem correctly by themselves
> > > (eg:
> > > debootstrap), and for users who already completed the transition.
> > > It
> > > also gained a flag file that stops the package from updating the
> > > system, clearly marked as making the system unsupported.
> > > 
> > > A MR is pending for debootstrap [1] to make use of this new
> > > package and
> > > file flag when --variant=buildd is passed, so that buildds can
> > > continue
> > > to be unmerged-usr until the CTTE says otherwise, as per decision
> > > above.
> > > 
> > > Once deboostrap is updated and deployed on the buildds, a
> > > "usrmerge |
> > > usr-is-merged" dependency will be added to the Priority:
> > > essential
> > > init-system-helpers package, and uploaded to unstable to complete
> > > the
> > > transitions for all installations that are older than buster or
> > > that
> > > have been manually installed as unmerged-usr. Any system not
> > > upgraded
> > > will be considered unsupported, and any package that doesn't work
> > > on
> > > the only supported layout will be considered RC-buggy, as per
> > > decision
> > > above. No special installation or upgrade path will be necessary,
> > > the
> > > normal apt upgrade/install process works as expected, and the
> > > transition happens from a maintainer script and it does not
> > > require to
> > > be ordered before or after any other package installation or
> > > upgrade.
> > > 
> > > All software has bugs by nature, and this will be no exception.
> > > But
> > > with Ubuntu having done an enormous amount of QA for us in the
> > > past
> > > years, especially in the almost 12 months since 21.10 and 22.04
> > > LTS
> > > have been released, without revealing any major issues, and with
> > > the
> > > new Piuparts coverage, and with all upstream software having been
> > > exercised in the new layout for the best part of a decade in most
> > > distributions, it is really not going to get any better.
> > > 
> > > The patch from user uau that the dpkg maintainer rejected in the
> > > past
> > > has been submitted to the existing bug [2] for completeness (with
> > > permission from the author).
> > > It will not be necessary to initiate or complete the migration to
> > > merged-usr, and we will not hold back waiting for a resolution on
> > > it,
> > > given the maintainer has made his intentions abundantly clear on
> > > the
> > > matter as recently as four months ago [3]. The patch is presented
> > > simply because it will likely be necessary, in that or any other
> > > form,
> > > to lift the moratorium on moving files between packages manually,
> > > whenever the CTTE decides that should happen. Whatever happens
> > > (or
> > > doesn't) to that patch/bug will not hold back the plan discussed
> > > here.
> > > 
> > > Do any of the Technical Committee members believe that this plan
> > > does
> > > not comply fully with their decision quoted above?
> > > 
> > > Thank you!
> > 
> > Status update:
> > 
> > - piuparts is running and I am not aware of any issues found so far
> > - usrmerge has been uploaded and has migrated to testing with the
> > new
> > flag and package
> > - reportbug MR still waiting on review/merge
> > - mmdebstrap has been updated and uploaded to unstable
> > - debootstrap has been updated, uploaded to unstable, migrated to
> > testing, uploaded to stable-backports
> > 
> > Today I talked to the buildd team on IRC regarding the buildds. A
> > preference was expressed for getting the new debootstrap via
> > stable-
> > updates rather than backports. Moreover, it was mentioned that
> > there
> > are still 11 buildd machines running on oldstable.
> > 
> > So I have backported and tested the debootstrap change on top of
> > the
> > versions shipped in buster and bullseye, and filed p-u bugs:
> > 
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016168
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016169
> > 
> > We are hoping these can make it in time for the next oldstable
> > point
> > release, which is scheduled for next week or so, before EOL.
> > 
> > If we can't make it, then I will go back to the buildd team and
> > propose
> > to go via the stable-backports and oldstable-backports-sloppy
> > routes.
> > 
> > Once the buildds have the debootstrap changes deployed, then we
> > will
> > upload init-system-helpers with the usrmerge | usr-is-merged
> > dependency. A notification about the transition will be sent to the
> > debian-devel mailing list when that upload happens.
> 
> Small update:
> 
> The debootstrap changes are all uploaded to stable-p-u and oldstable-
> p-
> u and accepted for the next point releases. The point releases have
> also been scheduled for September the 10th.
> 
> So as soon the buildds have been updated to those point releases
> after
> the 10th, I will proceed with uploading init-system-helpers with the
> new dependency.

Big update: with the new point releases done, it's a matter of
hours/days until the buildds get the new debootstrap, so we are almost
ready.

In minutes I will upload to experimental a new version of init-system-
helpers with the usrmerge | usr-is-merged dependency, so that we can do
some last minute testing.

I am travelling from tomorrow until Thursday, so I intend to do the
upload to unstable and kick the transition into high gear sometimes
around EOD on Thursday evening.

A mail to debian-devel will be shortly sent with a notification today,
and to debian-devel-announce on Thursday following the unstable upload.

-- 
Kind regards,
Luca Boccassi

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


Reply to: