Re: [draft] Draft text on Init Systems GR
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> Here is my proposal. It is unfortunately quite long. The reason is
> that I am trying to address the dysfuncdtional patterns I have seen over
> the past few years, and give specific remedies.
I wish that a GR had the moral suasion that would get everyone to be
excellent to each other, but I'm somewhat dubious. I'm not a huge fan of
trying to tackle that in the same GR as the technical questions, but I
respect why you want to do so and I would still vote this above further
discussion.
As with Dmitry's proposal, I'm not seconding this because it's not my own
first choice, but I would vote this above further discussion and I'm
satisfied that it's clear about the Policy implications.
> * Ideally, packages should not Depend on or Recommend systemd, and
> should be fully functional with all init systems. This means (for
> example) that daemons should ship traditional init scripts, or use
> other mechanisms to ensure that they are started without systemd.
> It also means that desktop software should be installable, and
> ideally fully functional, without systemd.
I think using Depend and Recommend here adds more confusion than clarity
since a lot of software doesn't Depend or Recommend systemd the package.
Instead, the dependency is on libpam-systemd or systemd-sysv or udev, and
there are different mechanisms in place to handle (or not handle) those.
Thankfully, I think the first clause here is redundant with the rest of
the paragraph anyway, and you can just say "Ideally, packages should be
fully functional with all init systems" and continue as you did.
> * systemd provides a variety of facilities besides daemon startup.
> For example, creating system users or temporary directories.
> Current Debian approaches are often based on debhelper scripts.
> In general more declarative approaches are better. Where
> - systemd provides such facility
> - a specification of the facility (or suitable subset) exists
> - the facility is better than the other approaches available
> in Debian, for example by being more declarative
> - it is reasonable to expect developers of non-systemd
> systems including non-Linux systems to implement it
> - including consideration of the amount of work involved
> the facility should be documented in Debian Policy (by textual
> incorporation, not by reference to an external document). The
> transition should be smooth for all users. The non-systemd
> community should be given at least 6 months, preferably at least 12
> months, to develop their implementation. (The same goes for any
> future enhancements.)
> If policy consensus cannot be reached on such a facility, the
> Technical Committee should decide based on the project's wishes as
> expressed in this GR.
This all sounds workable to me as a Policy editor.
> * Negative general comments about software and their communities,
> including both about systemd itself and about non-systemd init
> systems, are strongly deprecated.
This sense of deprecated is (I think) en_UK, or at least it reads oddly to
this en_US reader. I'm mentally translating it as "discouraged," but I
wonder if something like "are not acceptable within the Debian Project"
might be closer to the meaning you're intending.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: