Daniel Kahn Gillmor writes ("Re: Re-Proposal - preserve freedom of choice of
init systems"):
> nevertheless, runit behaves differently when it is pid 1 than when it is
> used in a subordinate role to another initsystem. If i'm upstream and
> i'm building mechanisms that integrate with runit *as it behaves as pid
> 1*, the implication seems to be that my work would not be welcome in debian.
Are you saying that a daemon author would want to write code which
only worked if runit was pid 1 ?
This question of daemon startup is a red herring, I think. It is
generally easy to solve the problem with some kind of wrapper or tool,
even if a daemon only starts up in a particular way.
> I like both postgresql and runit, and am really happy that both these
> things are in debian. But postgresql isn't RC-buggy just because the
> system service doesn't start automatically when i choose to use runit as
> pid 1.
postgresql wouldn't be RC-buggy if it _never_ started automatically.
That would just be an annoying bug.
And the GR text is quite careful: it doesn't say that failure to work
with one init system is worse than any other bug. It is only
_requiring a specific init system to be pid 1_ which is forbidden.
That's the exactly correct criterion because it is pid 1 which you can
only have one of. A user can have as different non-pid-1 daemon
supervisors as they like so there is no problem with a daemon
requiring a particular supervisor - provided that supervisor can work
(well enough) when not pid 1.
Ian.
--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/21569.15983.134642.422...@chiark.greenend.org.uk
