On Sat, 2022-09-10 at 13:37 +0100, Luca Boccassi wrote: > 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. Hello Debian CTTE, A few remaining bugs were solved, and an announcement went out to d-d- announce as planned, and the upload of i-s-h done as agreed previously. Unfortunately Adam Borowski has decided to engage in hostile and destructive behaviour in an attempt to sabotage the migration. Out of nowhere, he has uploaded two hostile NMUs (which have been reverted): https://tracker.debian.org/news/1362982/accepted-init-system-helpers-165nmu1-source-into-unstable/ https://tracker.debian.org/news/1362985/accepted-init-system-helpers-1651nmu1-source-into-unstable/ It goes without saying, but of course none of what the changelogs say is true, as you well know. I'd like to request the CTTE to intervene and put an end to this behaviour, so that the agreed plan based on your votes can be brought to conclusion with plenty of time to spare before Bookworm's freeze. Thank you! -- Kind regards, Luca Boccassi
Attachment:
signature.asc
Description: This is a digitally signed message part