Ian Jackson <ijack...@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 (r...@debian.org) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
