On 10/17/2014 12:06 PM, Ian Jackson wrote:
> 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 ?
Consider a tool that integrates in some way with /etc/runit/1 or
/etc/runit/2 or /etc/runit/3, which are only relevant for systems with
runit as pid 1 (see runit(8) for more details). Such a tool should not
be RC-buggy just because it's useless on a system that uses systemd or
sysvinit.
> 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.
so to be clear, it's not (and shouldn't be) an RC bug if a service fails
to start automatically on a system with a non-default init system, right?
>> 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.
I'm glad to hear that.
> 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.
If the requirement is testing a literal string match against
/proc/1/cmdline or $(readlink -f /sbin/init) or whatever, then that's
pretty silly, and surely that's *already* a bug that upstream would be
grateful for a fix. in this case, we don't need a GR.
But if the requirement is "hey, i'm not going to work without something
else on the system performing functionality X", and a given init system
*doesn't provide* functionality X, then it sounds like either a bug in
the lacking initsystem (should provide functionality X), or a
straightforward case of an explicit dependency. It could also be
resolved by making some part of the dependent package's functionality
more limited in scope, and saying "we can run but we can't to Y if we
don't have access to system functionality X". These are all legitimate
options for resolving the problem, and they're already available to
folks who want to work on them today. It sounds like the gdm issue was
actually resolved already through some combination of these approaches
(thanks to Aigars for the recap upthread). Why do we need a GR that's
unlikely to change this situation?
> 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.
we also limit debian systems to only one mail-transport-agent (e.g. exim
or postfix or courier, but not two of them at once), but we don't say
that mta-specific packages are RC-buggy, even if someone who has a
courier installation would really like to use a tool that currently only
integrates into postfix's mail-handling flow.
I'm going to stop commenting on this thread now and try to fix some bugs
that need fixing before the freeze.
Ian, thanks for raising the concern, and Lucas, thanks for floating an
alternative option. I hope we can spend our limited time fixing
existing bugs and working well together.
--dkg
Attachment:
signature.asc
Description: OpenPGP digital signature