Bug#727708: init system coupling etc.
Colin Watson <cjwatson@debian.org> writes:
> I'm currently undecided about whether I prefer the approach of setting
> technical policy under 6.1.1 or offering advice under 6.1.5. Bearing in
> mind all the process discussions we've had, I can see that it might be
> better to take the approach of offering technical advice rather than
> getting (re-)embroiled in a distracting procedural dispute about whether
> the Constitution entitles us to rule in advance on a subject that hasn't
> clearly been asked of us by some other first-responding maintainer.
I also think Keith's point that the normal process for setting Policy can
probably handle this is entirely correct. Certainly, I don't think there
will be substantial difficulties hammering out a Policy change given
advice from the TC. If there is, we can always deal with it at that
point.
> To start with, I therefore propose the following amendment to L. I
> think it is no weaker except in ways that we would agree were in fact OK
> if we found ourselves needing to rule on them specifically, and this
> addresses points that people have raised here. The first paragraph of
> the "loose coupling" section is replaced by the following:
> In general, software may not require a specific init system to be pid
> 1, although degraded operation is tolerable. The exceptions to this
> are as follows:
> * alternative init system implementations
> * special-use packages such as managers for init systems
> * cooperating groups of packages intended for use with specific init
> systems
> provided that these are not themselves required by other software
> whose main purpose is not the operation of a specific init system.
> Maintainers are encouraged to accept technically sound patches
> to enable improved interoperation with various init systems.
There's probably no chance that I will vote any version of L above FD, so
feel free to disregard this. But I think this is begging for some sort of
definition of "specific."
As written, it seems like it either requires all packages in the archive
add runit configuration, since otherwise they're not supporting all init
systems available in Debian, or alternately that any package that provides
a runit configuration and an OpenRC configuration and depends on runit |
openrc is fine, since it doesn't depend on "a" specific init system (it
depends on one of two specific init systems).
I don't think either of those are what you intend here. But I'm at a loss
as to what you *do* intend. Explain it to me like I'm five? :)
>> For the jessie release, all packages that currently support being run
>> under sysvinit should continue to support sysvinit unless there is no
>> technically feasible way to do so.
"packages" here should probably actually be "software" for all the reasons
discussed elsewhere.
> "Technically feasible" is so dependent on interpretation that I'm not
> sure whether it has enough real meaning. My instinct is to borrow some
> of the "exceptional cases" language from an earlier paragraph. On the
> other hand, "all packages that currently support being run under
> sysvinit" seems to mostly cover this well enough - it just takes me a
> couple of readings to get to it. Does this sentence bother anyone else?
> Russ, can you give an example of a package that currently supports
> sysvinit where you would be happy that it might stop supporting it for
> jessie due to a lack of technical feasibility?
Yes: logind. I think it should be fine to package a current version of
logind for Debian (meaning one that requires cgroups). I don't think
logind is part of the init system implementation; it's just another
program, like udev, that's built from the systemd source package. I don't
think it falls into any of the other exception cases. I think it's quite
reasonable to package a current logind for those who want to use it, even
though, by requiring cgroups, it currently only works with a corresponding
version of systemd as init. (Note that packaging it and having other
packages depend on it are distinct acts with separate implications.)
My understanding of the expected situation for jessie is that either
another cgroups implementation that works under sysvinit will be available
or someone will package logind 204 in a way that works with sysvinit.
Given that, it will be technically feasible for GNOME to depend on a
logind solution that doesn't require systemd. Therefore, this advice says
that GNOME should not depend on systemd as init. (This is all totally
obvious, of course, and I'm quite confident that the GNOME maintainers
don't need this advice to do the right thing, which is exactly why I will
probably be voting Keith's proposal first.)
But suppose that the alternative cgroups implementation doesn't
materialize. That specific logind implementation then *would* depend on
systemd as init. Does that mean that a logind that uses systemd cgroups
management is not permitted in Debian for the jessie release even if
another version of logind is also available?
Without the technically feasible qualification, this would be against our
advice since the current packaged logind doesn't require systemd as the
init system, and I see no reason for it to be.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: