Bug#727708: loose ends for init system decision
Russ Allbery writes ("Bug#727708: loose ends for init system decision"):
> Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> > For me it's a different proposition to suppose that _every_ daemon
> > should bring in these kind of dependencies.
>
> It's only going to be *every* daemon if we select systemd as the default
> init system, in which case we should be doing this in many daemons for
> either socket activation or for readiness notification as part of a proper
> systemd integration. [...]
Well, no. I think that even if we select upstart as the default, we
should enable the systemd community to provide as complete a set of
integration in Debian as they care to put the work in for.
That translates directly to an expectation that the maintainer of any
daemon package must be willing to accept reasonable systemd
integration patches.
If the systemd community is very dynamic (and certainly we can't fault
their dynamism so far) this may well translate to all or almost all
daemons. Certainly it could be expected to include most of the core
daemons where the extra dependencies are most troublesome.
So I think we need to say what we regard as "reasonable" patches, in
advance. As the Debian maintainer for uservd (for example), am I
entitled to decline to incorporate systemd integration into my package
on the grounds that the patch involves additional build- and runtime
dependencies which I consider undesirable ?
I don't consider it desirable to answer this question differently for
different daemons. We need to set out a clear rule for maintainers to
follow or we'll end up adjudicating a gazillion individual disputes.
And if the answer to this question is, in general, "the maintainer
must include the patch" then the logical conclusion is that it is OK
for every daemon in Debian to acquire these additional build- and
runtime dependencies. We would be telling non-Linux ports that they
need to arrange for these dependencies to be somehow provided despite
the lack of systemd on their architecture, or to have conditional
compilation of the systemd support in every daemon package.
If the TC's answer is "the maintainer may reject the patch", we would
be telling the systemd community that they need to improve and
simplify their integration.
I think the latter is the right approach, for two reasons. Firstly,
it is less work overall. Secondly, it is proper that the maintainers
of an init system should be encouraged to provide as simple and
nonintrusive an integration interface as possible.
> > This is particularly the case for build-dependencies on an avowedly and
> > intentionally non-portable program. Of course this can be made
> > conditional, but this is IMO too fiddly.
>
> Adding [linux-any] to the Build-Depends line is not too fiddly, and if the
> goal is to enable optional upstream support for systemd, that will be
> sufficient. Besides, in general, it's up to the packager to decide what
> is or is not too fiddly in how they want to package software.
Adding [linux-any] to the Build-Depends is not sufficient.
It is also necessary to make the actual source code conditionally use
sd_notify, using #ifdefs or other similar techniques. The conditional
compilation will have to be automated (perhaps with autoconf if the
package has it - an then we need new --with[out]-systemd configuration
options to avoid miscompilation; or perhaps in an ad hoc way if the
daemon doesn't use autoconf). The fact that the systemd-specific
command line option may or may not be compiled in needs to be
mentioned in the documentation, along with text which allows the user
to know whether it's included in the version they actually have.
This turns what could be a simple change into a multi-part epic
involving all of the components of the package: primary source code,
upstream build system and portability layer, Debian build system,
documentation, and so on.
And it might come about later that someone provides a portable
sd_notify so half (but just the right half) of the above would have to
be undone.
> Obviously, we should not add an unconditional build dependency for a
> library that isn't available on some of our ports to software that can
> work on those ports. But I think that's obvious. I'm happy to have us
> say that explicitly if if helps.
I think maintainers should not be required to introduce the additional
build- and runtime dependencies, if they do not wish to. Obviously if
they want to then that's fine by me.
> > It is very likely that Debian contributors will be implementing native
> > support for whatever readiness protocol, in the upstream parts of the
> > codebase. It is IMO appropriate for those contributors to get advice on
> > how to do this. Policy already gives advice on this kind of thing.
> > Given the context, and the fact that this advice is going to be read by
> > a lot of people as part of a big enhancement project, I think it's
> > appropriate for the TC to answer this question.
>
> If you feel like Policy should give advice on this, you can bring it up in
> the context of Policy.
The TC's mandate includes deciding on policy questions.
> I don't think the exact mechanism of integration is important
> enough for the TC to explicitly favor a particular mechanism, and
> different upstreams may have different approaches. I'm not seeing
> the important gain to Debian here in trying to standardize exactly
> how one tells a daemon to use socket activation or readiness
> notification.
I'm not saying it should be standardised.
I'm trying to give guidance to Debian contributors who will be doing
this work on many existing daemons. We would like them to do the best
thing and giving them non-binding guidance is correct.
> I also, for what it's worth, directly disagree with this advice with
> respect to systemd because I think compatibility with how systemd is used
> elsewhere is more important than any marginal gain from using a
> configuration method that's not inherited by subprocesses by default,
> particularly given that the standard systemd APIs include environment
> sanitizing. But I also don't see any point in arguing about it here,
> since I don't think this dispute is ripe (in the legal sense).
I'm afraid to say that this is quite a frustrating approach.
If it will help I can go through the motions of filing a policy bug,
having everyone point out that this is entangled with the whole init
system debate, and having you reject my proposal.
But perhaps we could just pretend I had done that ?
> If you do bring it up in the context of Policy and we can't resolve the
> debate there, it can get appealed to the TC and we can decide it here
> separately, but I think this is all premature, given that the whole point
> becomes basically moot if we don't pick systemd anyway.
No, it doesn't become moot. If we pick upstart then we still need to
tell maintainers what kind of systemd patches to accept.
If anything, it becomes moot if we pick systemd. It seems unlikely
that there would be a majority in the TC for picking systemd, and
separately a majority in the TC for overruling the systemd maintainers'
refusal to implement a simpler readiness protocol.
So a decision to pick systemd automatically comes with the expectation
that all daemons will get the new build- and runtime dependencies, and
maintainers will be expected to accept those patches.
> > Are you proposing then that the TC should decide the default init
> > system, but asmk people NOT to start converting packages until the
> > policy questions are settled ?
>
> Sure. I think that's what's going to happen anyway.
I don't think that's likely, unless we state it explicitly.
And I want the conversion work to be able to start as soon as
possible.
These questions are all entangled with the init system choice. Having
dealt with the primary issue the TC members will be in a good position
to dispose of these ancillary issues.
I think remanding contentious consequential issues back to the policy
process is a very unattractive option. It will just incur delay.
I'm happy with leaving uncontentious details to the policy process.
Ian.
Reply to: