Ansgar <[email protected]> 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 ([email protected]) <https://www.eyrie.org/~eagle/>
