Michael Stapelberg <stapelb...@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 (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
