gregor herrmann <gre...@debian.org> writes:
> What surprises me in this discussion: My very broad summary of the GR
> result was "systemd is the top priority, other init systems are
> supported on a best-effort basis", and now I'm reading statements which
> sound to me like "looking into new/future/niche init systems is ok-ish
> but we never meant sysvinit when we said 'alternate init systems'", and
> that's either a misunderstanding of some mails on my side or an
> interpretation I find implausible to draw from the text of the winning
> GR option.
The position that sysvinit specifically is a dead end but that Debian
should not lock ourselves into a single init system and instead be open to
using other init systems besides systemd was a position advocated by
several people during the GR debate, and if one held that position, it is
a reason to vote for the winning option B over option F (the focus on
systemd option). Certainly my understanding at the time was that option B
was intended to represent the folks with that position, possibly among
others.
Whether the folks who voted B over other options meant it in that specific
way is, of course, somewhat unknowable, and I'm sure at least some of them
didn't.
This discussion surprises me for a somewhat different reason. The winning
GR option contains this text, which I think is an evolution of text that I
asked for at the time to make things clearer from a Policy standpoint:
Packages may use any systemd facility at the package maintainer's
discretion, provided that this is consistent with other Policy
requirements and the normal expectation that packages shouldn't depend
on experimental or unsupported (in Debian) features of other packages.
Packages may include support for alternate init systems besides
systemd and may include alternatives for any systemd-specific
interfaces they use. Maintainers use their normal procedures for
deciding which patches to include.
I think this clearly and unambiguously says that maintainers can depend on
unit support and drop init scripts from their packages if they so choose,
and that this choice only requires as much justification as rejecting any
other patch or feature in their packages (and Debian is generally defers
to package maintainers here).
One of the GR discussion goals was to try to make all of the options clear
about the implications for whether or not maintainers could drop init
scripts from their packages or would be required to include them, and I
thought option B was one of the options that made it unambiguous that
maintainers could drop them. I assumed that if option B won, some
maintainers would drop init scripts, and therefore if folks wanted to
maintain a set of working init scripts, they'd need to look at different
options than ensuring they were incorporated into each package.
Apparently we still, after all that discussion, weren't on the same page
about this? That's really unfortunate, since that was one of the major
questions on which we were trying to get closure.
For the record, the current Policy language says:
Packages including a service unit may optionally include an init
script to support other init systems. In this case, the init script
should have the same name as the systemd service unit so that systemd
will ignore it and use the service unit instead. Packages may also
support other init systems by including configuration in the native
format of those init systems.
I have another pending patch that I need to finish revising that makes the
normative language here more explicit. The intended definition of "may"
here is the one from that patch, namely:
* The term *may* and the adjective *optional* are used to clarify cases
where it may otherwise appear that Policy is specifying a requirement or
recommendation. In those cases, these words describe decisions that are
truly optional and at the maintainer's discretion.
This was intended to reflect the result of the GR.
The dependency structure for indicating a logind requirement is a more
complicated question and I don't personally have any opinion about the
GR's implications for it.
--
Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
