After a discussion in #-devel today I reviewed packages using other
choices of "Rules-Requires-Root" than "no" and "binary-targets".  The
query [1] found two uses:

- wfrench 1.2.6-1.  This could just use "no"; a bug was filed[2].

- libcap2 1:2.44-1.  Uses it for running tests as root, but doesn't support
  fakeroot anyway.  Rules-Requires-Root can't however communicate this so
  additional knowledge is needed.

The complexity to support arbitrary additional keywords as choices of
R³ seems overkill given there is just one real user (libcap2) and the
current R³ specification doesn't handle that usecase fully either.

Therefore I suggest to deprecate using R³ values other than "no" and
"binary-targets" within Debian.

(Unrelated: R³: no should probably be recommended.)

Ansgar

  [1]: https://codesearch.debian.net/search?q=Rules-Requires-Root%3A+%5B%5Ebn%5D+path%3Adebian%2Fcontrol%24&literal=0
  [2]: https://bugs.debian.org/975635

What about 'Rules-Requires-Root: yes' ?

Cheers,

"yes" is currently not an allowed choice (the default is
"binary-targets").

Ansgar

What about it? The current policy doesn't support this value.

    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?

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.
I appreciate that you probably do care about the maintenance costs in
dpkg-dev, but our value functions probably diverge a bit there.

    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?

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.
I appreciate that you probably do care about the maintenance costs in
dpkg-dev, but our value functions probably diverge a bit there.

    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
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

Hello Ansgar,

We would definitely need input from the designers of the R³ system
before removing anything (to my knowledge, the design was led by Niels
and Guillem).  They were designing for the very long term, so I don't
think we can safely infer much from the present contents of the archive.

I'm also not really convinced by your arguments that having these other
possible values adds much of a burden.  This is not about code which has
to be updated, just text.  We do not expect newcomers to imbibe
everything in Policy.