"Theodore Y. Ts'o" <ty...@mit.edu> writes: > So mostly, this isn't going to be up to us. It's going to be up to > the upstream. Eventually, for each package where upstream has chosen > to use these technologies, our choice will be (a) to drop the package > from Debian, (b) add backwards compatibility support for systems which > haven't drunk the systemd kool-aid, or (c) mark that the package only > works for systemd.
> I think we've mostly accepted that we can't force package maintainers > to do (b), and for many packages, such as for example GNOME, (a) will > be a non-starter, which means we're left with (c). I don't think the analysis is *quite* that obvious, since much of (b) can be done in the form of implementing equivalent features to systemd. The unit file format is basically fine -- it might not be what everyone would have picked, but it's fairly straightforward to parse. Some systemd features are already implemented by start-stop-daemon; many others would be fairly straightforward to implement in at least a basic form (such as socket activation via a tcpserver-style wrapper, and even a lot of the namespace and capability support). A cron daemon could add a parser for systemd timer units and invoke the corresponding service unit via the same mechanism. And so forth. 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, without going all the way to saying that systemd will always be the init system. It's similar to what we did for /bin/sh (although this is of course much more complicated). The space between those options leaves the door open for folks who care about init system diversity to implement those features in some other way, such as via separate stand-alone binaries chained together with pipes and other normal UNIX tools. 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. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>