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