Russ Allbery wrote: > One of the options that I find interesting is to enumerate a list of > features in unit files that Debian supports, and require that any > Debian init system be able to handle unit files with those features. > This standardzes an *API* for both package maintainers and upstream
I sincerely hope that we never have to support multiple implementations of the unit file format with varying levels of support for its directives. The point of my mail was to propose acknowledging the end of the lowest-common-denominator approach. (Also, the surface area of systemd is far broader than just unit file directives, and many of the directives exist to integrate with other features.) > It's similar to what we did for /bin/sh (although this is of course > much more complicated). With /bin/sh, we just required that *if* you write #!/bin/sh you only use /bin/sh features. (And a non-bash /bin/sh already existed, as well as an industry standard defining the required behavior of /bin/sh, which pre-dated bash.) Critically, people *always* had the option to write #!/bin/bash if they actually used the features of bash. > Of course, this approach is not viable if it turns out that too few people > are interested in init system diversity sufficiently to do the reasonably > substantial implementation work required to maintain a competing > implementation of the systemd unit features we care about. Part of the problem is that the people interested in sysvinit don't tend to care about those features and often argue that others shouldn't care either, and the people interested in those features don't tend to care about sysvinit. It's difficult to motivate people to work on alternatives for a system they already have and prefer. That's leaving aside that a reimplementation of systemd's features will tend towards becoming systemd, and we have one of those already. What is the actual goal? As a limiting case to prove the point, suppose someone patched systemd to support running as a PID other than 1, underneath sysvinit, using mechanisms like prctl PR_SET_CHILD_SUBREAPER and cgroups to let it act like init without being PID 1. (By comparison, that would *not* be an especially hard problem.) Would that solve the problem of "must run under sysvinit"? Something tells me that that solution would not be considered acceptable by folks who want to keep running sysvinit. There are additional unspoken constraints here. It seems evident based on the history of such efforts that there is *not* sufficient people/interest/motivation to reimplement the majority of systemd features, let alone doing so in a way that meets the additional constraints imposed on such solutions. That support isn't going to materialize out of hope. What would it take for us to document the situation and move forward, rather than assuming that it might change?
