XPost: linux.debian.bugs.dist
From:
guillem@debian.org
Hi!
On Sun, 2025-01-05 at 22:47:31 +0000, Ian Jackson wrote:
Package: dpkg
Version: 1.22.13
Control: block 1092190 by -1
As a heads up, please read my reply more as an exploratory one with
a pinch of push back, instead of a directed vector to a wontfix kind
of thing, as I'd like to understand exactly how you see this being
problematic, in case we missed some stuff, and also because this feels
like adding support for new stuff that is immediately intended to
start a deprecation cycle to get rid of it in N release cycles. Because
in the end the whole exercise here is to try to eventually be able to
fully get rid of the need for fakeroot in our tooling stack (which we
cannot fully do even now, but we are going in that direction).
It seems likely to me that there will continue to be packages in the
wild which this behavioural change will break - particularly including packages not part of Debian, packages from old Debian release, and
perhaps whole derivative distros.
I've actually been reluctant to perform this default switch in the past
for two main reasons, one was the amount of potential breakage (silent
or aborting) in the archive (where we have ways to easily detect silent breakage), and the other was for the unknown potential silent breakage
in out of archive packages (potential aborting breakage should be part
of the deal when updating the toolchain IMO).
Given that the archive was in a quite manageable state, and Niels
provided actual numbers, my remaining concern was about out of
archive silent breakage. We went over the potential cases that could
affect these packages, where the packaging uses dpkg-buildpackage to
build, but does not use a helper like debhelper (which handle rootless
builds automatically), and might do the equivalent of:
1) chown fails w/ checked exit code, aborts
2) chown fails w/o abort, silent breakage
In here chmod (say to set-user-ID) does not matter because the chown
success or failure always wins.
So for the problematic case 2), which are packages not using a helper
that would transparently support rootless builds, and would thus end
up with non-root owned paths, for which Niels proposed a fatal check
in dpkg-deb for "normal users" (unless run with --root-owner-group),
which had a feel as a good general approach but was potentially
problematic in two fronts. One with the check itself as that would
require cooking vendor specific user/group policies, which would break
with foreign builds, as dpkg-deb is really a cross tool, and the other
with the checks being fatal, as that might potentially get in the way
of legitimate usages of the tool. After pondering about this I thought
that warning in dpkg-deb if the build root directory was not root owned
was a portable compromise solution that gives us the properties we are
looking for, which would still turn the category 2) problem above into
a non-silent one. (This is implemented in dpkg-deb 1.22.13.) I could
also see turning the warning into an error (and adding a
--no-check-fsys or similar to disable it) to not let any non-aborting
breakage through, if the warning alone is still considered too risky.
Said that. It's true that packages can of course still break (either
with an abort, or with a dpkg-deb warning), but an extremely quick and backwards compatible way to unbreak them would be to add an «Rules-Requires-Root: binary-targets», which should do the right thing
even with old dpkg-dev tools that do not understand it (as then it would
be the default).
Note that when we designed the R³ interfaces and behavior we took care
of defining them so that new packages declaring these interfaces,
after having been adapted, should still work with old tooling.
In order to allow us to build old packages with new tooling, or
out-of-distro packages, or whatever, I think dpkg-buildpackage should
have a way to request the previous (bookworm-and-earlier) behaviour.
This is the part I'd like to apply this slight push back. :) I don't
think we can guarantee to build old packages with new tooling,
otherwise we could not make progress. We do change language toolchains
which break old stuff, change default flags, do ABI transitions like
the time64 one, etc. Out of archive packages need to update the
packaging to new standards too, new lintian errors, new more strict
syntax checks, etc., when switching Debian release or upgrading the
tooling they use.
While I agree it's important to have ways to back off from a change,
to ease with such transitions, in this case we have provided that
already from the beginning. And what matters most is not failing
silently.
I looked through the manpage and found --rules-requires-root, but that
says that it disregards the Rules-Requires-Root field entirely, which
isn't right. (And might also break things...)
It's certainly not ideal, as it would run things under say fakeroot
that would otherwise not need to, but it should be always safe, and
it was designed and intended to be able to build any new package,
including the ones that have explicitly opted out of root builds
(otherwise I'd consider that a bug in the package).
I thought I could propose for dgit to use only this option if
«dpkg-buildtree is-rootless» returned failure, but that program was
only introduced in the 1.22.x series which would not be of much help.
Another option for dgit, could be to check whether the package
contains «Rules-Requires-Root: no» (because dpkg-build-api(7) being
the other factor influencing the default value, was also only
introduced in 1.22.x, so it would not affect older releases), but
perhaps combining this with the previous «is-rootless» and then using --rules-requires-root conditional on these would be a viable
alternative.
Could we please have a command line option to just change the default,
so that trixie's dpkg-buildpackage can be used in circumstances where bookworm's would have worked ?
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)