Bug#733452: init system daemon readiness protocol
Ian Jackson <ijackson@chiark.greenend.org.uk> writes:
> The systemd protocol is troublesome because it requires too much code
> in the daemon, leaving the daemon author with the trilemma which has
> previously been discussed.
This statement as written is only true if you're unwilling to link with a
shared library, a stance that I personally do not understand. I do
realize that's the position you hold, and you're entitled to your opinions
on that front, but I think it's important to include that disclaimer here.
When linking with libsystemd-daemon, which is a tiny shared library that
adds no particular difficulties and that can be trivially stubbed out on
systems that don't have it, adding systemd daemon readiness to my package
required eight lines of upstream code (three for the actual call, five to
stub the call out if the library was not found). The build system support
for optionally compiling with the appropriate libraries was comparable:
six lines of code, two variables added to CPPFLAGS and LDADD lines in
Makefile.am, and an autogen-time dependency on pkg-config (which many
packages are already using for other reasons). So a total of 14 lines of
code, which I certainly didn't find to be "too much."
I think one's position on this depends heavily on whether one considers
optionally linking with a shared library to provide systemd integration
and not providing that integration if the library was not available at
build time to be reasonable. Personally, I find that entirely reasonable,
and therefore cannot agree with your characterization of the systemd
situation.
> I conclude therefore that we should design another simple protocol -
> preferably, a variation on one of the existing ones - and have (at
> least) both Debian's systemd and Debian's upstart implement it.
> Obviously this needs input from both upstreams. Given the poor
> relationship between the two main projects which would need to implement
> the same protocol, and the possibility that we might have to carry this
> in a local patch in Debian if we can't reach agreement with one or other
> of the upstreams, I think it would be best if this design discussion
> were refereed by the TC.
Despite the fact that I personally have no problems with the existing
systemd notification protocol, I would certainly welcome a compromise that
more people found reasonable. I'm a bit skeptical that such a thing would
happen, but if people would like to work on it, by all means.
However, I don't think this fits the role of the TC, and indeed I think
refereeing that discussion would be contrary to my view of section 6.3.5
of the Debian constitution.
> Also, though should not block the decision on the default init system
> on this more open-ended design work (and associated negotation); but
> it is probably worth waiting with starting a mass package conversion
> until we know what startup protocol we want.
Agreed, with the caveat that I don't think we should discourage upstreams
from adding support for one or both of the synchronization protocols.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: