Re: Is an MBF and unblock for packages introducing new files in /bin or /sbin or /lib in Bookworm acceptable at this stage?
Hi Luca, On Mon, 22 May 2023 00:03:46 +0100 Luca Boccassi wrote: > On Sun, 21 May 2023 at 20:31, Luca Boccassi wrote: > > > > On Sun, 21 May 2023 at 20:29, Christoph Berg > > wrote: > > > > > > Re: Luca Boccassi > > > > If we were to do a MBF against packages that in _Bookworm_ have > > > > introduced new files in /bin, /sbin or /lib*, would you accept > > > > the consequent mass unblock request? > > > > > > Fwiw, I would restrict that to packages that didn't have files in > > > these directories before. Telling a maintainer that they should > > > continue install foo.service to /lib/systemd, but the newly > > > introduced bar.service needs to got to /usr/lib/systemd seems > > > like a lot of extra work and asking for bugs to happen. > > > > Yes, this (the number of files mentioned) already excludes things > > that are installed by dh addons and so, such as unit files. > > Here's the list of affected packages for binaries: > > abpoa > eprover > coq-hierarchy-builder > intel-cmt-cat > nbd-server > systemd > toybox > drbd-utils > finit > finit-plugins > multipath-tools > runit Please exclude runit from the list as /lib/runit/ was not empty in Bullseye. Regards, Lorenzo > nut-modbus > nut-i2c > nut-server > open-iscsi > openrc > resolvconf > iproute2 > f2fs-tools > ifupdown-ng > multipath-tools > libpam-modules-bin > > PAM modules: > > cockpit-tests > libpam-python > libpam-alreadyloggedin > libpam-chroot > google-compute-engine-oslogin > systemd-homed > > Library new ABI or minor versions: > > libbrlapi0.8 > libc6 > libcap2 > libcgroup2 > libdbus-1-3 > libdmraid1.0.0.rc16 > libcap-ng0 > libexpat1 > libfuse3-3 > libgpg-error0 > xfsprogs > libreadline8 > libkeyutils1 > liblzma5 > libncurses6 > libncursesw6 > libntfs-3g89 > libnutclient2 > libnutscan2 > libparted-fs-resize0 > libparted2 > libproc2-0 > libsepol2 > libtinfo6 > libupsclient6 > zlib1g > > The libraries are just minor version increase in most cases, so the > symlinks are often unchanged and cannot be moved, so I'd leave them > where they are. So that's 23 packages for binaries and 5 for PAM > modules moving from un-triplet to triplet location. > > Kind regards, > Luca Boccassi >
Re: Is an MBF and unblock for packages introducing new files in /bin or /sbin or /lib in Bookworm acceptable at this stage?
On Sun, 21 May 2023 at 20:31, Luca Boccassi wrote: > > On Sun, 21 May 2023 at 20:29, Christoph Berg wrote: > > > > Re: Luca Boccassi > > > If we were to do a MBF against packages that in _Bookworm_ have > > > introduced new files in /bin, /sbin or /lib*, would you accept the > > > consequent mass unblock request? > > > > Fwiw, I would restrict that to packages that didn't have files in > > these directories before. Telling a maintainer that they should > > continue install foo.service to /lib/systemd, but the newly introduced > > bar.service needs to got to /usr/lib/systemd seems like a lot of extra > > work and asking for bugs to happen. > > Yes, this (the number of files mentioned) already excludes things that > are installed by dh addons and so, such as unit files. Here's the list of affected packages for binaries: abpoa eprover coq-hierarchy-builder intel-cmt-cat nbd-server systemd toybox drbd-utils finit finit-plugins multipath-tools runit nut-modbus nut-i2c nut-server open-iscsi openrc resolvconf iproute2 f2fs-tools ifupdown-ng multipath-tools libpam-modules-bin PAM modules: cockpit-tests libpam-python libpam-alreadyloggedin libpam-chroot google-compute-engine-oslogin systemd-homed Library new ABI or minor versions: libbrlapi0.8 libc6 libcap2 libcgroup2 libdbus-1-3 libdmraid1.0.0.rc16 libcap-ng0 libexpat1 libfuse3-3 libgpg-error0 xfsprogs libreadline8 libkeyutils1 liblzma5 libncurses6 libncursesw6 libntfs-3g89 libnutclient2 libnutscan2 libparted-fs-resize0 libparted2 libproc2-0 libsepol2 libtinfo6 libupsclient6 zlib1g The libraries are just minor version increase in most cases, so the symlinks are often unchanged and cannot be moved, so I'd leave them where they are. So that's 23 packages for binaries and 5 for PAM modules moving from un-triplet to triplet location. Kind regards, Luca Boccassi
Re: Is an MBF and unblock for packages introducing new files in /bin or /sbin or /lib in Bookworm acceptable at this stage?
On Sun, 21 May 2023 at 20:29, Christoph Berg wrote: > > Re: Luca Boccassi > > If we were to do a MBF against packages that in _Bookworm_ have > > introduced new files in /bin, /sbin or /lib*, would you accept the > > consequent mass unblock request? > > Fwiw, I would restrict that to packages that didn't have files in > these directories before. Telling a maintainer that they should > continue install foo.service to /lib/systemd, but the newly introduced > bar.service needs to got to /usr/lib/systemd seems like a lot of extra > work and asking for bugs to happen. Yes, this (the number of files mentioned) already excludes things that are installed by dh addons and so, such as unit files. Kind regards, Luca Boccassi
Re: Is an MBF and unblock for packages introducing new files in /bin or /sbin or /lib in Bookworm acceptable at this stage?
Re: Luca Boccassi > If we were to do a MBF against packages that in _Bookworm_ have > introduced new files in /bin, /sbin or /lib*, would you accept the > consequent mass unblock request? Fwiw, I would restrict that to packages that didn't have files in these directories before. Telling a maintainer that they should continue install foo.service to /lib/systemd, but the newly introduced bar.service needs to got to /usr/lib/systemd seems like a lot of extra work and asking for bugs to happen. Christoph
Is an MBF and unblock for packages introducing new files in /bin or /sbin or /lib in Bookworm acceptable at this stage?
Hello Release Team, If we were to do a MBF against packages that in _Bookworm_ have introduced new files in /bin, /sbin or /lib*, would you accept the consequent mass unblock request? I am asking beforehand as there's no point in going through the effort if you don't, the advantage is only if we can sort it before Bookworm ships, and the bugs would become invalid and be closed as soon as it does as per moratorium otherwise. By Helmut's count, there's around 178 such files to move. The project should probably have added this as a distro-wide rule as part of the moratorium, but that ship has sailed. Thanks! Kind regards, Luca Boccassi
Bug#1035904: dpkg currently warning about merged-usr systems (revisited) (was: Re: DEP 17: Improve support for directory aliasing in dpkg)
On Sun, 21 May 2023 at 15:51, Ansgar wrote: > > On Sun, 2023-05-21 at 16:25 +0200, Helmut Grohne wrote: > > On a process level, I think I miss attempts to resolve this with the > > dpkg maintainer in a constructive way. > > The patch was already suggested to the dpkg maintainer and rejected. > > > Does anyone mind just closing the bug? > > Yes, I do. > > Please pass a resolution that you don't want to override the dpkg > maintainer and that telling derivative users to configure their system > in a way that will cause breakage is okay to do for packages in Debian. I do as well. Recently a very strong consensus emerged that even accidentally causing damage and/or incompatibility to downstreams/external use cases is strongly frowned upon, to say the least. Talking the talk is easy, now we have to walk the walk. Both the warning and the 'unmess' tool cause significant damage and break cross-compatibility, so they both need to be removed. A "mind the moratorium" message would be of course very sensible to have. Kind regards, Luca Boccassi
Bug#1035904: dpkg currently warning about merged-usr systems (revisited) (was: Re: DEP 17: Improve support for directory aliasing in dpkg)
On Sun, 2023-05-21 at 16:25 +0200, Helmut Grohne wrote: > On a process level, I think I miss attempts to resolve this with the > dpkg maintainer in a constructive way. The patch was already suggested to the dpkg maintainer and rejected. > Does anyone mind just closing the bug? Yes, I do. Please pass a resolution that you don't want to override the dpkg maintainer and that telling derivative users to configure their system in a way that will cause breakage is okay to do for packages in Debian. Ansgar
Bug#1035904: dpkg currently warning about merged-usr systems (revisited) (was: Re: DEP 17: Improve support for directory aliasing in dpkg)
Hi Ansgar, I'm speaking with a CTTE hat here, but not representing CTTE consensus. On Wed, May 10, 2023 at 11:47:42PM +0200, Ansgar wrote: > Dear ctte, please consider overruling the dpkg maintainer to include > the patch from #994388[1]. I think we need to reject this request on multiple levels. On a social level, I see that you are frustrated with how dpkg is being maintained and how communication does not work out in practice. While part of that can be attributed to the dpkg maintainer, this goes both ways and the way you refer this matter to the CTTE without even attempting to resolve it by other means just serves to deepen that dispute. I see that the dpkg maintainer has recently contributed constructively to the discussion about how dpkg can be part of a solution for the problems resulting from the /usr merge. I have a hard time saying the same about your interaction here. Therefore, I think your request should be rejected as not being serious. On a process level, I think I miss attempts to resolve this with the dpkg maintainer in a constructive way. The present discussion clearly shows that dpkg's support for how Debian deals with merged /usr is lacking. We are dealing with multiple file-loss scenarios (something we otherwise consider grave) and issuing a warning about such behaviour seems fine to me. On the other hand, much of the project seems to agree that the way this warning is worded is far from optimal and evidently leads to confused users. And while it may seem that any attempt at resolving may lead nowhere, the same can be said about our dpkg maintainer's concerns about our /usr-merge strategy and him pointing out real problems affecting Debian installations in practice. Given the recent constructive communication, I think it is far from clear that this option is exhausted. In particular, acknowledging the problems presented and proposing strategies for dealing with them could go a long way towards a cooperative solution. At present, I see the options to keep and to delete the warning on the table, but there clearly is unexplored middle ground. As such, I think your request should be rejected as not having exhausted the solution space. On a technical level, Debian's support for merged /usr is currently founded on the moratorium preventing breakage. Please observe that this moratorium applies to Debian and Debian only. We have implemented processes to validate this. If a derivative wants to use merged /usr (which probably every derivative should), it certainly needs to prevent breakage in some way - presumably using a similar process. I think that the cost of patching dpkg is minor compared to the cost of a process that prevents breakage arising from our merged /usr strategy. Given this, a warning-by-default (worded in a better way) for derivatives actually can be a good thing, because it makes derivatives aware that they cannot just ignore merged /usr, but have to act. As such, I think your request should be rejected since the measure is technically reasonable in principle. Does anyone mind just closing the bug? At the same time, I recommend changing the warning. The amount of feedback we get regarding the warning should make it clear that the current wording is still seen as offensive and causes confusion. Keeping the warning in its current form also serves little but deepening the dispute. For instance, the wording "going behind dpkg's back" may be considered technically correct, but it also can be objectively described as passive aggressive. Just deleting this aspect and instead saying "This system uses merged-usr-via-aliased-dirs which violates core assumptions of dpkg." would probably keep the intended message in a less confrontational way. Elaborating that file loss is being mitigated by a process (moratorium) on Debian would also help. Looking into the wiki, a recommendation of dpkg-fsys-usrunmess should caution that using it now breaks other tool's assumptions such as systemd and is generally not being tested with QA anymore. Even if one were thinking that the warning were appropriate as is, adapting it again due to community feedback would demonstrate empathy and be a step towards a cooperative solution. I think our priority should be finding a way to terminate the moratorium. Helmut
