Bug#947847: opentmpfiles & opensysusers, and its use in the Debian policy

[Thomas Goirand]

Hi Simon,

Thanks for your long message, and engaging in the discussion. I very
much appreciate that it looks like we're engaging in a passionate
technical discussion ! :)

> I think the situations to be supported are:
>
>* System booted with systemd. We should consistently use systemd's
>  implementation of these tools, because otherwise, any missing
>  features or behaviour differences in opentmpfiles could break systemd
>  units that are (quite reasonably) relying on a versioned dependency
>  on systemd (>= 321) being sufficient to provide all the interfaces of
>  systemd 321.

First, my understanding is that tmpfiles isn't there for .service files,
as the systemd units have their own implementation of this (see for
example the directives: RuntimeDirectory=, StateDirectory=,
CacheDirectory=). Do you agree? I have removed the use of these in the
past, because Stretch didn't have the feature (especially,
RuntimeDirectory, I have no experience with the other 2), though it
looks like working well in Buster, no?

Second, it looks like are you saying that only systemd is able to
implement new things. I don't believe that's the case. For example,
upstream in open{sysusers,tmpfiles} could decide to implement a new
feature, or even *us*, on the Debian side of things, could do that. This
would be especially easy with open{sysusers,tmpfiles} because they are
easy to understand shell scripts.

I also don't agree that systemd should have any kind of priority on
other implementation. It doesn't make sense, and this would only makes
Debian look like being obviously biased toward systemd. Let's try to
adopt a pragmatic view on this.

Reasonably, one possible path here, could be to drop the systemd
implementation, if we have at least feature parity, and prefer to avoid
difference of behavior (in such case, the open{tmpfiles,sysusers} would
be superior because working on all platforms). However, it is too early
to have an opinion about this right now (have you tested opemtmpfiles
and opensysusers? how does it compare to the systemd implementation? I
haven't done that work myself yet...).

>* System booted with a different init system, or no init system at all
>  (chroot or container). Either implementation could be OK; we should
>  probably prefer the systemd implementation, because it's the
>  reference implementation of these interfaces, but having it be
>  possible to use opentmpfiles/opensysusers on Linux would make it
>  easier to prototype those packages, even if we end up with only the
>  non-Linux ports using them.
>
> On -devel, Sam Hartman has recommended being consistent about which
> implementation is used for each port (systemd-tmpfiles for Linux
> systems, opentmpfiles for non-Linux), and there's certainly value in
> that.

Sorry to say it this way, but none of the point of argumentation above
look, to my eyes, valid: you aren't saying technically why the systemd
implementation would be better. The only point of argumentation that
you're giving, is that the systemd version is "the reference". This
looks like coming from an emotional feeling rather than a technical
analysis of the problem.

At this point in time, I'd say it is a way too early to be able to tell.
The only thing I'd like to see happen is being able to easily switch
from one implementation to another, so that we can easily test things.
*THEN* (and only then), we can discuss what to do, and what the Debian
policy should look like.

Now, let's go back to the reason why I opened this bug in the first
place: make it possible to switch from one implementation to the other.

There's a few way we can do it:
1- dpkg-divert in open{sysusers,tmpfiles}
2- have systemd split systemd-{sysusers,tmpfiles} into 2 separate packages
3- use update-alternatives

I think that 1- is overkill. Hopefully, you will agree.

The option 2- is probably too much of a micro-packaging practice, which
ftp masters don't really like (and I tend to not like it too). Though if
you are willing to split /bin/systemd-{sysusers,tmpfiles} into a
different package, and then we get open{sysusers,tmpfiles} conflict with
that package, that also works, it is easy to implement, and users will
be able to switch between the 2. However, I very much prefer the use of
update-alternatives, because we can have both installed at once, and
decide to use a specific one if we want to, though I'm ok with
conflicting packages (if that's really your proposal, though I'm not
really sure that it's what you're saying: please clarify).

Which is why I end up preferring option 3-. Which of the 3 options is
your preference? Are you also ok that we decide to use /bin/systemd-X as
the installed alternative? This way, we have nothing else to patch.

Cheers,

Thomas Goirand (zigo)