Re: Proposal for next steps for systemd-related policy
>>>>> "Sean" == Sean Whitton <spwhitton@spwhitton.name> 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 <https://www.debian.org/vote/2019/vote_002>. I thought it
>> might be helpful to lay out a possible way to sequence the work.
Sean> Thank you for writing this.
>> 1. Downgrade the requirement to include an init script in a package with a
>> systemd unit to "encouraged." This is the direct outcome of the GR, so
>> I think we should make this change before the next normative upload,
>> since there's no point in Policy being inconsistent with the GR result.
>>
>> I think there's some discussion to be had here about whether the
>> correct level is "encouraged" or "optional." I'd also like to revise
>> and merge my change that adds "encouraged" first, although if we decide
>> "optional" is correct, that sequencing is, well, optional.
Sean> Under the new description of these words in #944920, I think we would
Sean> have to use 'encouraged'. That new text says that 'optional' is meant
Sean> to be used purely for clarificatory purposes, but incorporating the
Sean> result of the GR into Policy would not be a matter of clarifying
Sean> something else said in Policy, so far as I can tell.
Sean> I think it's useful for 'optional' to be reserved for its clarificatory
Sean> role.
>> 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.
>>
>> My thought process here is that while the GR permits packages to start
>> using systemd facilities directly, doing that without somehow declaring
>> that requirement in package metadata seems likely to cause bugs and
>> upgrade issues, so we should try to provide some better facilities. I
>> think there's an obvious gap here where we need a mechanism to declare
>> a dependency on a system facility (as distinct from a package that may
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 service unit and may install an
init script.
But if you've gotten to a point where service units are recommended all
the time (no service unit but an init script is a bug) then: Maintainers
are recommended to install a service unit. If maintainers do not
install a service unit, they are encouraged to install an init script;
in other situations installing an init script is optional.
That at least is my take on what Proposal B implies in the new policy
terminology.
BTW, I like the new terms! Great work
Reply to: