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

Re: BITS from the DPL For September/October 2019

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

Reply to: