Bug#975637: debian-policy: deprecate Rules-Requires-Root other than "no", "binary-targets" in Debian
Hello, On Sun 02 Oct 2022 at 09:03PM +02, Niels Thykier wrote: > 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. Many thanks for the input. Could you just confirm that there isn't any info in Policy which isn't also in dpkg documentation? If so, then if someone particularly wants to see this gone from the manual they can prepare a patch for seconding. > 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 Cool. I think that would be fine too. -- Sean Whitton signature.asc Description: PGP signature
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 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.
Bug#975637: debian-policy: deprecate Rules-Requires-Root other than "no", "binary-targets" in Debian
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: > > - 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.) 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 signature.asc Description: PGP signature
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 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
Bug#975637: debian-policy: deprecate Rules-Requires-Root other than "no", "binary-targets" in Debian
> "Ansgar" == Ansgar 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? 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.
Bug#975637: debian-policy: deprecate Rules-Requires-Root other than "no", "binary-targets" in Debian
On Tue, Nov 24, 2020 at 01:49:59PM +0100, Bill Allombert wrote: > > 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. > > What about 'Rules-Requires-Root: yes' ? What about it? The current policy doesn't support this value. -- WBR, wRAR signature.asc Description: PGP signature
Bug#975637: debian-policy: deprecate Rules-Requires-Root other than "no", "binary-targets" in Debian
On Tue, 2020-11-24 at 13:49 +0100, Bill Allombert wrote: On Tue, Nov 24, 2020 at 01:37:53PM +0100, Ansgar wrote: > > Therefore I suggest to deprecate using R³ values other than "no" > > and "binary-targets" within Debian. > > What about 'Rules-Requires-Root: yes' ? "yes" is currently not an allowed choice (the default is "binary-targets"). Ansgar
Bug#975637: debian-policy: deprecate Rules-Requires-Root other than "no", "binary-targets" in Debian
On Tue, Nov 24, 2020 at 01:37:53PM +0100, 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: > > - 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. What about 'Rules-Requires-Root: yes' ? Cheers, -- Bill. Imagine a large red swirl here.
Bug#975637: debian-policy: deprecate Rules-Requires-Root other than "no", "binary-targets" in Debian
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: - 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=0 [2]: https://bugs.debian.org/975635
