On Mon, 14 Dec 2020 15:01:52 -0700 Sean Whitton
<spwhit...@spwhitton.name> wrote:
Hello Ansgar,
On Tue 24 Nov 2020 at 01:37PM +01, Ansgar wrote:
> Package: debian-policy
> Version: 4.5.1.0
> Severity: normal
>
> 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:
>
> [...]
>
> 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.)
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.
--
Sean Whitton
Hi,
Here is my view in short: As I see it, only the values `no` and
`binary-targets` for `Rules-Requires-Root` makes sense for the *policy
defined targets*[1] at the moment. Accordingly, Debian policy can
probably reduce the field to only cover `binary-targets` and `no` (and
describe the remaining values as "[they] will mostly behave like `no`,
but read more in the dpkg documentation for concrete the non-policy
relevant use-case")
In theory, you could use `Rules-Requires-Root` to cover the static
ownership cases (where you need to chown files and store that ownership
in the deb). However, that would require people to consistently use
fakeroot with -l + -s (which, to my knowledge, no one does) - failure to
do so would just silently loose the ownership and the files would end up
with the wrong owner.
On a related note, both Guillem and I agreed a while back that ownership
(among other) should ideally be specifiably without using chown. While
a concrete method has not yet materialized, I am not working on
supporting static ownership via chown in debhelper (nor do I plan to do
so), so in practice `binary-targets` is the only reliable way to setup
static ownership for any package built via debhelper[2].
So in summary, with the current tooling, only `no` and `binary-targets`
make sense for *policy defined targets* and I am not aware of anything
that would change that.
Thanks,
~Niels
PS: As for the adding a recommendation to use `Rules-Requires-Root: no`
where possible. I would second such as change. Over half of all Debian
source packages in testing have the value, and adoption has been quite
fast despite very little push from Guillem and I on it. For me, the
recommendation would be documenting public sentiment on this topic.
Source: https://trends.debian.net/rulesreqroot_testing-percent.png
[1]: There is a set of values for asking dpkg-buildpackage to provide
(fake)root for custom targets, which might make sense for users/packages
- but since those would be custom targets, Debian Policy should not care
about these targets. But it probably has to mention the field can have
other values than specified and that is okay for very rare cases.
[2]: When `Rules-Requires-Root` is not (effectively) `binary-targets`,
debhelper will pass `--root-owner-group` to `dpkg-deb`, which neuters
any filesystem specified ownership.