[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Proposal: General Resolution on Init Systems and systemd Facilities

Ansgar <ansgar@43-1.org> writes:
> On Thu, 2019-11-14 at 15:08 -0500, Sam Hartman wrote:

>> Unless the project or relevant parties have agreed otherwise, systemd
>> facilities, where they exist and are stable and supported by the
>> systemd maintainers, should be preferred over Debian-specific ways of
>> solving the same problem unless the Debian approach has clear and
>> obvious advantages.

> I don't think this is really what we might want: when there are multiple
> competing options, Debian-specific or not, developed under the systemd
> umbrella or not, which on Debian packagers decide to use should only be
> on merit, i.e. there shouldn't be an implicit "we choose systemd by
> default".

This is the reason why I put "supported by the systemd maintainers" here,
although that may not be sufficient to address your concern.  But the idea
I had in mind was that the decision of whether to support the systemd
facility would be an informed choice that takes into account concerns like
that.  I know there are some systemd facilities that the systemd
maintainers in Debian have little desire to support as an archive-wide

> I believe we are mostly thinking of systemd-tmpfiles or -sysusers here
> which do have a "Debian-specific (and currently imperative)" and
> "systemd-provided" implementation, but as a slightly different example
> consider resolved / unbound: here one is systemd-provided, but the other
> non-Debian-specific. But there is no inherit advantage of "resolved"
> over "unbound" just because it is developed as part of systemd.

This is probably out of scope for this paragraph because a stub resolver
is not Debian-specific nor do we choose just one.  The only thing that
might be in scope is a discussion of what stub resolver to use by default,
but the existing practice of not running a stub resolver has some obvious
advantages (thus triggering that last clause).

> ```
>    Choice 3: Affirm systemd as preferred init system; allow tooling 
>    evolution

>    The Debian project recognizes that systemd service units are the
>    preferred configuration for describing how to start a
>    daemon/service. Packages should include service units or init 
>    scripts to start daemons and services. [No change here.]

>    The project commits to open evolution of tooling in the future.
>    This explicitly includes the possible adoption of facilities
>    provided under the systemd project umbrella such as systemd-tmpfiles
>    or systemd-sysusers if such facilities are considered useful and
>    the preferred available implementation. The project recognizes this 
>    might create additional work for, for example, non-Linux ports, but
>    believes this alone should not be considered a blocker for adoption.

>    [Following paragraphs as before]
> ```

I don't really know what "commits to open evolution of tooling" means.  I
think what you're trying to say is that the project will make decisions
about standardized tooling on the basis of their technical merits for a
systemd install rather than their portability to non-systemd systems?

Russ Allbery (rra@debian.org)              <https://www.eyrie.org/~eagle/>

Reply to: