Bug#975637: debian-policy: deprecate Rules-Requires-Root other than "no", "binary-targets" in Debian
On Tue, 2020-12-01 at 08:00 -0500, Sam Hartman wrote:
> > > > > "Ansgar" == Ansgar <ansgar@debian.org> writes:
Ansgar> using other choices of "Rules-Requires-Root" than "no" and
Ansgar> "binary-targets". The query [1] found two uses:
Can you help me understand how options other than binary-targets or no
were supposed to work/what they make possible?
I have found the policy text in this area a bit opaque.
I'd like to understand what we'd be giving up if we adopt your
proposal.
Is this facility not used simply because everyone reads it and like me
goes "huh what does that really mean," and never gets around to
thinking it through? Or is it an extension point we actually don't
need?
It looks like it is designed to allow even smaller parts than the
"binary" targets as a whole to run without fakeroot, but (IMHO) the
goal should be to move away from having d/rules require root for
anything at all. So to me it looks like an extension point that is not
needed.
That the *only*[1] user in the archive after several years is libcap2
seems to support this hypothesis. Also libcap2 uses it for tests that
explicitly require real root, yet Rules-Requires-Root says:
+---
| This field intentionally does not enable a package to request a true
| root over fakeroot.
+---[ Policy 5.6.31.1 ]
To run tests as root, we have autopkgtest. This doesn't happen at build
time, but buildds don't offer real root anyway, so not much of a
difference.
Also, how much of the complexity cost you are concerned about has
already been paid and how much of it is ongoing? Ignore for the moment
> maintenance in packages like dpkg-dev and sbuild.
I'm basically asking how many new tools over time are likely to need to
care about this complexity if we keep it.
You don't only need to implement it and maintain the implementation,
but when you teach people about Debian packaging (or they read Policy
to learn about it), you need to teach people about this. That's an
ongoing cost.
The R³ parts currently require two sections (5.6.31 and 4.9.2) with
several subsections (5.6.31.1 to 5.6.31.3). That is a lot for
something only a single package uses (and for a usecase that R³ is
explicitly not supposed to cover).
There are other problems like any package trying to use a non-standard
or new keyword will regress to the old "binary-defaults" default until
all tools are updated to support the new keyword. That the list of
keywords is intentionally incomplete also makes it hard to implement in
tools.
I appreciate that you probably do care about the maintenance costs in
dpkg-dev, but our value functions probably diverge a bit there.
dpkg-dev can continue to main the support if wanted; there are other
functions dpkg support, but that aren't used in the Debian archive like
I believe vendor patch series.
Ansgar
Reply to: