Bug#727708: init system other points, and conclusion
Michael Stapelberg <stapelberg@debian.org> writes:
> 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).
I agree with Michael on this point. I think he would be doing a
disservice to both Debian and upstreams to carry these sorts of changes as
distribution-specific patches.
Support for SIGSTOP is, I think, a debatable point, and I understand Ian's
position. I also understand Lennart's position. If I were Lennart, I
probably would have added it, but I can understand why he wants to
discourage it. I don't think it's a good long-term solution. I do think
a strong argument could be made for adding it, though... but not as a
distribution-specific patch. That seems like a recipe for user confusion.
On $PATH searching, I just completely disagree with Ian. Adding $PATH
dependencies to unit files is something I consider a straight-out bad
idea. Patching unit files to adjust paths, even if it requires
distribution-specific patches, is significantly better. I would have told
him no to this request were I systemd upstream as well. It makes the
whole init system more fragile in ways that aren't helpful.
> 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!
I concur with this. I have had exceptionally good interactions with both
systemd upstream and the systemd package maintainers.
I think Ian had the misfortune of having the two points he cared the most
about both be objections to fundamental design decisions and places where
upstream felt that implementing his approach would make the system more
fragile. In one case, I agree with them. Rejecting such requests does
not make for a bad upstream. I would argue that's upstream's job.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: