Re: Proposal for next steps for systemd-related policy

[Sam Hartman <hartmans@debian.org>]

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