Hi Ian, My apologies in advance for answering only to one email, but quoting several. It could be that you had some threading in mind which my reply might break.
Ian Jackson <ijack...@chiark.greenend.org.uk> writes: > * systemd's readiness protocol is an unattractive implementation > target for an upstream daemon author. I think this is an important > weakness, if it remains unaddressed. We talked about this in #732157 already, but I think it is worth summarizing it here: for modern daemons, libsystemd-daemon is a widely available library which can be trivially added. In case dependencies absolutely need to be kept at a minimum, the less preferably alternative of dropping that library’s code into the daemon’s code base exists. If both of those are unsatisfactory, one can implement it by oneself, which you deem unattractive. I tend to agree, but I think you are overstating this as an “important weakness”. Most daemons do not even need any readiness notification whatsoever. Using socket activation or forking after initialization is enough. > I'm treating the config fragments as part of the packaging, rather > than as something upstreamish, because in practice they are inherently > un-debuggable without access to a system running the corresponding > daemon. They are also small enough that any distro which cares could > easily ship their own (and might need to). I don’t understand that reasoning. By “daemon”, do you mean init system or actual daemon for which the service file is intended? Also, why would a distro ship its own? Even in the rare case that an upstream-provided service file is (and stays!) unsuitable for Debian, a patch is all that is necessary. > There was less support from the Debian policy manual. Perhaps there > is some other systemd Debian packaging guidance somewhere which I > didn't find. There is https://wiki.debian.org/Systemd/Packaging which is the first Google hit for “debian systemd packaging”. Until a while ago, the page was changing a lot while we were still hashing out details about packaging. By now, I’d say we could add this to the policy manual. > The unit files were somewhat harder to write. It wasn't just that the > systemd unit file offered a great many more options, although that was > a factor. The two-unit split of systemd socket activation was more > fiddly. And systemd wants each directive to be in a particular > "[section]". See also http://0pointer.de/blog/projects/systemd-for-admins-3.html (“How Do I Convert A SysV Init Script Into A systemd Service File?”). I do admit that this is hard to find if you don’t know it exists. It _is_ linked to from the main systemd website, though, but I cannot expect that everybody reads the entire body of documentation. > Also, the approach to the systemd integration introduces a new runtime > package dependency on "init-system-helpers", which despite its > generic-sounding name actually contains only helpers for systemd and > is maintained in Debian by the systemd maintainers. It has already been pointed out elsewhere in the thread, but given that I introduced this package, I’d like to stress again that I will gladly accept other init system’s helper programs to this package. The package name and description is not misleading; I really mean it. > The same appears to be the case for systemd's interactions with Debian > as a downstream. Pressure has had to be applied on issues such as > separate /usr (and much documentation still contains claims that this > is "broken"); I asked for systemd to be able to execute programs from > PATH rather than requiring unit files to specify the absolute path and > was rebuffed (#...) #732981 is the bug reference that you didn’t include by accident, I think :). > This is exacerbated by the fact that systemd's Debian maintainers are > (IMO) much too deferential to upstream. > […] > In short, the systemd community feels, to me, arrogant and > controlling. I am far from the first to say something like this, but > I've now experienced things for myself and I concur with the > criticism. Given that I am the one who responded to both your referenced bug reports, let me provide my perspective in this bug. Upstream does not want to provide the features you asked for, and I’ll not comment on that, apart from stating that it’s not obvious that they are a good idea (one can see that from the discussion on the bugs). You then asked for these features to be carried as a patch in the Debian systemd package, and both requests were rejected. I think this is what you refer to when saying “the systemd Debian maintainers are much too deferential to upstream”. The reason why we don’t want to carry these patches is that they significantly alter the public API between systemd and the daemon authors — but in Debian only! As stated in the bug, my rule of thumb is whether people need to differentiate between Debian and “all other distributions”. E.g., with your simpler readiness notification proposal, daemon authors could use that on Debian, but would need to conditionally compile code for Debian while they also still need to ship code for the current API. This is not a simplification at all. Similarly, with the $PATH thing, we’d introduce the need to patch _every_ single upstream unit in our Debian packages. Even worse, unit file authors would be surprised when their unit file does not work on other systems when it was written and tested on Debian (where one could use $PATH). > Furthermore, in my view the responses of Debian's upstart maintainers > to my bug reports about upstart have been exemplary. There has been, > for example, no resistance (from them or AFAICT from upstream) to > supporting the systemd socket activation protocol. I’d like to point out that with features that are universally accepted (and especially by upstream), the response of systemd contributors was exemplary, too. Zbigniew Jędrzejewski-Szmek in particular has reacted to documentation clarification requests and even feature requests like the globbing of units in record time. Thanks for that! -- Best regards, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
