Bug#948115: Revise init script Policy based on GR result

Package: debian-policy Version: 4.4.1.2 Severity: important Per recent (non-BTS) discussion, this patch is a first draft at reconciling Policy with the recent GR result. Summary of changes: * Change section headings and anchors to reflect the more general topic * Add recommended naming

Re: Proposal for next steps for systemd-related policy

Sam Hartman writes: > I haven't been following the consensus around making service units more > recommended. Ignoring that discussion, but folding in the GR: > Maintainers are recommended to install at least one of a service unit or > init script. Maintainers are encouraged to install an

Re: Bug#944920: Revise terminology used to specify requirements

Sean Whitton writes: > Let's definitely reconsider those 'must' requirements in response to > this work, but let's not commit ourselves to the idea that it's always a > bug for the Release Team's conception of an RC bug, and Policy 'must' > requirements, to disagree. > The Release Team's

Bug#944920: Revise terminology used to specify requirements

Russ Allbery writes: > I agree, but let's also fix existing incorrect wording. I reviewed > every instance of may and optional in Policy, and I think this larger > diff will make wording (mostly) consistent. I've tried not to change > the sense of any of these Policy statements (even though a

Bug#944920: Revise terminology used to specify requirements

Sean Whitton writes: > On Sun 17 Nov 2019 at 05:48PM -08, Russ Allbery wrote: >> is being used.) You must not include the ``/etc/rcn.d`` directories >> -themselves in the archive either. (Only the ``sysvinit`` package may do >> -so.) >> +themselves in the archive either. (Only the

Re: Proposal for next steps for systemd-related policy

> "Sean" == Sean Whitton writes: Sean> Hello Russ, Sean> On Sun 29 Dec 2019 at 10:47am -08, Russ Allbery wrote: >> This is a tentative proposal for next steps from a Policy standpoint given >> the result of . I thought it >>

Re: Proposal for next steps for systemd-related policy

Simon McVittie writes: > Do you mean "systemd features", or do you mean system services more > generally? I'm hopeful that we can solve the more general problem, or at least make forward progress on it, since as you mention we've had this problem for years and have worked around it in various

Re: Proposal for next steps for systemd-related policy

On Sun, 29 Dec 2019 at 10:47:44 -0800, Russ Allbery wrote: > 3. Start a discussion on debian-devel to see if we can come up with some >idea for how to declare dependencies on availability of system >services. Do you mean "systemd features", or do you mean system services more generally?

Re: Proposal for next steps for systemd-related policy

Hello, On Sun 29 Dec 2019 at 04:36pm -08, Russ Allbery wrote: > Right, what I think is in scope for Policy is advising packagers on which > readiness signaling mechanism to use if upstream supports several. If one > is relatively new to packaging daemons, this may not be something on one's >

Re: Bug#944920: Revise terminology used to specify requirements

Hello, On Sun 29 Dec 2019 at 11:20am -08, Russ Allbery wrote: > Paul Gevers writes: >> On 21-11-2019 13:59, Paul Gevers wrote: > >>> [Disclaimer: the words below are as a member of the release team, but >>> not necessarily those of the team. We haven't discussed this yet.] > >> We have had a

Re: Proposal for next steps for systemd-related policy

Hello Russ, On Sun 29 Dec 2019 at 10:47am -08, Russ Allbery wrote: > This is a tentative proposal for next steps from a Policy standpoint given > the result of . I thought it > might be helpful to lay out a possible way to sequence the work. Thank you