Steven Chamberlain writes ("Bug#727708: init system other points, and
conclusion"):
> Policy may need to explain whether hard systemd requirement is
> permissible, if it should be expressed in package dependencies, or what
> it should do otherwise (e.g. refuse to start, fail with error message,
> fall back to something with reduced functionality).
Right. In general I would prefer to see as good a support as is
feasible, in the particular case.
> If policy requires keeping functional sysvinit scripts around for
> jessie,
I think the TC is very likely to require this. We haven't
specifically heard from everyone on this point but both Russ and I
(who disagree on several other important points) agree on it and none
of the other TC members have disagreed.
> and/or (more controversially) can discourage the use of specific
> non-portable functionality - which I think would be things like "expect
> fork" or socket activation - I'm not necessarily saying this is a good
> idea, but it would obviously work in our favour.
You are right that "expect fork" is nonportable in that sense.
I don't think socket activation is non-portable. It would be
straightforward to write a wrapper program which set up the relevant
sockets and passed them to the daemon via either the systemd or
upstart socket activation protocols. Such a wrapper could be used for
any daemon which needed it. I guess the work involved would be a day
or two to produce something fully tested and documented.
The same is true for dbus activation, if I'm not mistaken, but I
haven't looked into this in any detail.
> If non-Linux ports end up running and testing daemons on an alternate
> init system *anyway*, I'd love for that work to benefit GNU/Linux users
> who dislike the chosen default init system and want to use what we're
> using instead. And vice-versa, anyone running such a system and
> finding/fixing startup issues, would likely be helping the ports.
Yes, absolutely.
Thanks,
Ian.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
