Re: Integration with systemd
"Theodore Y. Ts'o" <tytso@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 (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: