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

Re: Proposal for next steps for systemd-related policy

Hi, I broadly agree with what you said. Russ Allbery writes: > 2. Do nothing further before January 6th. It's still the holidays, and >subsequent steps are going to require some discussion, and I think it's >worth taking a breath. This, particularly. >My thought process here is

Re: Proposal for next steps for systemd-related policy

Russ Allbery writes: > 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 radar to look at, but there are substantial,

Re: Proposal for next steps for systemd-related policy

Simon McVittie writes: > On Sun, 29 Dec 2019 at 10:47:44 -0800, Russ Allbery wrote: >>We probably also want to recommend Type=notify where possible and >>Type=exec where not, over Type=forking, when the daemon supports >>that. > I'm not sure what you mean by "where possible" - it'll

Re: Proposal for next steps for systemd-related policy

On Sun, 29 Dec 2019 at 10:47:44 -0800, Russ Allbery wrote: >We probably also want to recommend Type=notify where possible and >Type=exec where not, over Type=forking, when the daemon supports that. I'm not sure what you mean by "where possible" - it'll usually be possible to implement

Proposal for next steps for systemd-related policy

Hi all, 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. 1. Downgrade the requirement to include an init script in a package with a