Re: Bug#1019409: Bug#993161: pam: some remaining changes for DPKG_ROOT
Hi, Quoting Steve Langasek (2022-09-10 22:16:55) > > > > For the record I do not consider this an override requiring a > > > > supermajority and would abide by a majority TC decision. > > > > Thank you for your input. The TC can just issue advice after reviewing > > > the proposed changes, in this case. An alternative would be to word the > > > resolution such that it counts as advice if we have a simple majority > > > and an override if we have a supermajority. I'd prefer the former, but > > > it would be good to hear from Helmut about it. > > > AIUI, Steve's objection is substantially that this is quite an invasive > > change to make across our toolchain, and should be discussed on debian-devel > > before just being implemented package-by-package (rather than any particular > > objection to the approach). Is that correct? > > I think that's a fair characterization, yes. > > I support the goal of making it easier to bootstrap ports. I also don't > even see a cleaner way to accomplish this than what's proposed. But I think > there's a duty, when making distro-level changes, to have a project-level > discussion about what's being proposed and why, and to get consensus on it, > not just file a bunch of bug reports on individual packages. I think there's a duty, when maintaining a package, to at least send a short reply to bugs against your package and even more so, if pinged multiple times and your co-maintainer explicitly waiting for you and thus this non-action resulting in blocking other people's work. We invoked the TC not because we did not want to discuss on d-devel but because you have kept silent since February 2021 when we filed our initial bug #983427 against pam. In hindsight, we should've written to d-devel, yes. Helmut and myself are working on a mail to send to d-devel to get this done now in the sense of "better late than never". We didn't think that such a mail was necessary because there are only 10 source packages (including pam) that require the DPKG_ROOT variable in their maintainer script for this mechanism to work (that's why I wouldn't classify this as "distro-level change") and because the required changes to maintainer scripts result in zero behaviour changes on anything that is not early-bootstrap. >From my side, I'd be fine with the TC pausing any action on this issue and waiting for our mail to d-devel first. This is assuming that if there is no opposition to the DPKG_ROOT idea, that Steve then also has no objection against merging our patch. Helmut, what do you think? Thanks! cheers, josch signature.asc Description: signature
Re: Bug#993161: pam: some remaining changes for DPKG_ROOT
On Sat, Sep 10, 2022 at 05:36:13PM +0100, Matthew Vernon wrote: > On 09/09/2022 19:45, Sean Whitton wrote: > > Hello, > > On Thu 08 Sep 2022 at 10:09PM -07, Steve Langasek wrote: > > > For the record I do not consider this an override requiring a > > > supermajority and would abide by a majority TC decision. > > Thank you for your input. The TC can just issue advice after reviewing > > the proposed changes, in this case. An alternative would be to word the > > resolution such that it counts as advice if we have a simple majority > > and an override if we have a supermajority. I'd prefer the former, but > > it would be good to hear from Helmut about it. > AIUI, Steve's objection is substantially that this is quite an invasive > change to make across our toolchain, and should be discussed on debian-devel > before just being implemented package-by-package (rather than any particular > objection to the approach). Is that correct? I think that's a fair characterization, yes. I support the goal of making it easier to bootstrap ports. I also don't even see a cleaner way to accomplish this than what's proposed. But I think there's a duty, when making distro-level changes, to have a project-level discussion about what's being proposed and why, and to get consensus on it, not just file a bunch of bug reports on individual packages. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: PGP signature
Re: Bug#993161: pam: some remaining changes for DPKG_ROOT
On 09/09/2022 19:45, Sean Whitton wrote: Hello, On Thu 08 Sep 2022 at 10:09PM -07, Steve Langasek wrote: For the record I do not consider this an override requiring a supermajority and would abide by a majority TC decision. Thank you for your input. The TC can just issue advice after reviewing the proposed changes, in this case. An alternative would be to word the resolution such that it counts as advice if we have a simple majority and an override if we have a supermajority. I'd prefer the former, but it would be good to hear from Helmut about it. AIUI, Steve's objection is substantially that this is quite an invasive change to make across our toolchain, and should be discussed on debian-devel before just being implemented package-by-package (rather than any particular objection to the approach). Is that correct? But that Sam is unsold on the technical approach and wanted input from Steve before agreeing? Regards, Matthew
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
