[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#975637: debian-policy: deprecate Rules-Requires-Root other than "no", "binary-targets" in Debian



On Mon, 14 Dec 2020 15:01:52 -0700 Sean Whitton <spwhitton@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.


Reply to: