On Fri, 09 Aug 2019 at 17:12:17 +0800, Benda Xu wrote:
> Simon Richter <s...@debian.org> writes:
> > For that to happen, we'd have to define .service files as an API
> > though, which would feature-freeze them, and I'm not sure the systemd
> > people would be happy about that.
>
> Thank you for sharing your thoughts. I also think adding a
> compatibility layer is the best way to move forward.
>
> With more upstream packages providing systemd-.service by default, it is
> more expansive for the systemd team to break the existing .service API.
> We could consider it to be freezed in practice, or at least backward
> compatible.
Frozen is not the same as backwards compatible. systemd can add new
functionality, and other projects can start to depend on that new
functionality, without it being a backwards compatibility break.
All these examples "go back in time" a bit so that I can talk about systemd
features that literally do exist, but please imagine that they didn't exist
yet and were going to be added in a future systemd version.
When a file format / feature set is backwards-compatible but not frozen,
you can have this situation:
- systemd adds an option, like RuntimeDirectory=
- service "foo" starts relying on that option for correct functionality
- the hypothetical compatibility layer does not support that option
- foo doesn't work correctly
or this:
- systemd adds a feature that is not reflected in .service files, like
support for creating named pipes with "p" in tmpfiles.d(5) files
- service "foo" ships a tmpfiles.d file that makes use of that, and
the invocation of foo in foo.service relies on the creation of that
named pipe for correct functionality
- the hypothetical compatibility layer does not integrate with tmpfiles.d,
or does integrate with tmpfiles.d but doesn't support "p"
- foo doesn't work correctly
or this:
- systemd adds support for activation of D-Bus services that have a
SystemdService configured
- dbus changes its ExecStart command line to include --systemd-activation,
which makes dbus-daemon delegate activation of those services to systemd
- the hypothetical compatibility layer does not implement activation of
systemd services (it would be hard for it to do so - it isn't systemd)
- dbus doesn't work correctly
The compatibility layer might not implement a feature because nobody has
implemented it yet, or might never implement it because the authors of
that compatibility layer don't like it, or might never implement it
because it's unimplementable without basically being systemd.
To a large extent, the design of units and service files *is* systemd. If
you don't like the design of systemd, and you set out to implement
something that implements the same "API" by reading the man pages and
implementing all the features described there, it's hard to see how you
could get a result that doesn't have at least some of the same properties
that you don't like about systemd.
smcv
