|
|
Log in / Subscribe / Register

The Grumpy Editor's guide to surviving the systemd debate

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 9:32 UTC (Fri) by anselm (subscriber, #2796)
In reply to: The Grumpy Editor's guide to surviving the systemd debate by dlang
Parent article: The Grumpy Editor's guide to surviving the systemd debate

Too many people related to systemd have publicly stated that they consider supporting anything else to be a waste of time

How many of these “too many people” are Debian developers?

You're re-stating the position of the systemd core team. This has precisely no bearing on what the maintainers of unrelated packages in Debian (those which might or might not come with upstream systemd or sysvinit support) ought to do. In particular, the systemd core team can't be compelled to do or not do something by Debian passing a GR. On the other hand, if package upstreams decide to avail themselves of systemd-specific features, it is unreasonable to expect that the Debian maintainers of such packages develop support for other init systems on the off-chance; it is much more reasonable to expect that those people who actually want to use the package in question with another init system should do the work, and that the Debian package maintainers simply propagate the outcome for the benefit of other users. (If the Debian package maintainers do decide that they don't mind doing the extra work themselves then that is of course also fine.) This appears to have worked in the GNOME case even in the absence of a GR.

Finally, taking outside patches for extra feature support isn't actually unusual in the Debian ecosystem, and it is safe to say that the vast majority of Debian developers – who are generally reasonable folks – will welcome that kind of assistance. If the Debian developer in charge of a package is adamantly opposed to accepting a sensible-looking and technically sound patch simply because they don't like what it does, there are ways of resolving such impasses that do not involve project-wide GRs. So far in the systemd case this hasn't happened; we have had the opposite case where a maintainer didn't want to take on a patch that contributed systemd support for their package because they didn't like systemd – but as I said there are easier ways to sort this out.


to post comments


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds