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