Simon Richter dijo [Wed, Oct 30, 2019 at 12:46:21PM +0100]: > Hi, > > On Tue, Oct 29, 2019 at 10:38:32PM +0100, Thomas Goirand wrote: > > > If we have such vote again, I'll continue on this direction: I'd prefer > > if we didn't have to vote. > > >From a Policy perspective, packages are supposed to integrate into the > system by providing init scripts, and Policy has a lengthy definition of > how init scripts need to behave. > > We need to at least mention systemd unit files at some point, so action is > needed, and that action needs to be backed up by a vote to avoid being > more divisive than necessary. I completely agree with this -- It is time for Policy to specify at least the equivalence of init scripts to systemd units. Policy has always documented standard practice, so it was right for it to lag before doing this. It is, I guess, time to revisit... > So far, systemd adoption has been mostly smooth sailing because the > ecosystem effectively consists of two blocks: the systemd core, which is > centrally coordinated, and some traditional Unix daemons hanging off it, > but essentially not integrating. This is about to change as projects > actually start using systemd. Yes. And that will be a thorn for people investing time in maintaining Debian as an init-system-agnostic distribution. Or worse, following the examples you provide :-\ > (...) > All that requires way more complex unit files than anything we normally > deal with in Debian, and we need to decide how much control we want to keep > over package integration here, because that is what Debian does: take > upstream software and provide a coherent integrated whole. > > By leaving it unspecified in Policy what systemd features are expected in a > particular Debian release, we essentially take a back seat in what should > be our core competence. Although by taking advantage of them, we will not be able to support on an equal tier other init systems. > If the project feels that these use cases are not worth supporting, then > that is a policy decision that needs to be voted on, not just silently > implemented, last but not least so we can update our marketing materials > with footnotes on the "universal operating system" tagline, and users (who, > after all, are one of our priorities) can adjust their expectations. > > So yes, having a vote is necessary at this point. We've neglected setting > policy way too long, the scope of the project is unclear at this point, and > people are pulling in all kinds of directions. Very much agree with this. It is time to revisit and think clearly about what we win/lose, and where are we heading as a project. Probably the only way forward is via the full GR process.
Attachment:
signature.asc
Description: PGP signature