Re: opentmpfiles & opensysusers, and its use in the Debian policy
On 1/3/20 2:33 AM, Sam Hartman wrote:
> Secondly, by using systemd-tmpfiles when we can, we gain support for any
> additional features that are implemented.
That's where I don't agree. While it's nice to have such a declarative
system, I don't think it's reasonable to impose the implementation of
any change to systemd to all the other init systems. At some point, *we*
must be able to decide.
> My recommendation would be to have one implementation of this interface
> per architecture; use the systemd one on architectures where it works.
My recommendation would be to be able to have some kind of CI to make
sure that both implementations are working the same way (obviously, I
will not have enough time available for this, unfortunately...). I don't
see why we would need to prefer one implementation over the other, if
they provide the same facility, there's no technical advantage to do so.
You are being obviously biased toward systemd here. Just try to think a
2nd time: the same way, what if opentmpfiles implements a new feature
that is *not* in systemd implementation? There, we have an exit
strategy: we can decide to stop using the systemd implementation
completely, since the alternative will work everywhere.
I'd like also to point to you that the alternatives are much easier to
maintain: they are written in shell script only, and are completely
independent from anything else. That's what a lot of people (including
myself) thought should have been done for systemd, and these 2
implementation really proves that it is possible. Similarly, the way
systemd is trying to take over DNS resolving and NTP in an "integrated"
way is the wrong way of doing things, and hopefully, Debian folks and
systemd lovers will be able to understand that fact (don't get me wrong:
understanding and recognizing that systemd should be more modular, and
broken better into individual *independent* pieces, is orthogonal to
deciding how to use the said systemd facility).
> It will not.
> I think another question is more interesting though.
>
> Will having runtime selection of that interface harm Debian.
>
> My answer is that I think it might:
>
> * You might get the wrong version of tmpfiles implementation on a given
> system. The harm on a systemd system would be that you might not have
> a feature available.
This would be a bug that would need to be addressed then. Just like any
other bugs.
> * You might be tempted to restrict yourself to the subset of the
> tmpfiles and sysusers interface that all the implementations of the
> interface support.
Which would be perfectly fine. We did that for the bash -> dash
implementation of sh, because we found out dash was much faster. This
implied a loss of a lot of features. All we need to do is to balance
what we're doing, and see. If we think a feature is unimportant, maybe
it's best to forbid it (the right way, with a lintian warning/error) so
that we make sure all implementations are working. This is where the
Debian policy becomes important. Note that this works in both cases,
where the systemd or the alternative has a new thing.
> When there is a sufficient benefit, I
> think it would be fine to accept these costs.
That's another way to write what I wrote! :)
> Given that the systemd implementations will work for alternate inits on
> linux, I'd rather see us use them there.
> But I don't care that much.
> I'm just expressing an opinion about which policy Debian should adopt;
> if I'm in the rough that's okay with me.
If we have feature parity, or as if as I wrote above, we're ok with the
implemented features and think they are enough, then we could decide the
exact opposite way: choose the implementation that works everywhere, and
get rid of the systemd one (and maybe have systemd depend on the
alternative implementation), so that we know we'll have the same
behavior on all systems. Obviously, that's something to decide *later*,
once the alternatives have been tested long enough and we know they are
robust enough (which I currently cannot tell).
> You talk later about wanting to have a runit facility where you could
> create tmpfiles before starting a service rather than at boot.
> That seems cool, but that's going to be an entirely different interface
> than what we're talking about here.
> If packages stick tmpfiles units in the right place and do the right
> thing from a maintainer script, they expect their directories to exist
> even if their service never gets started (or their package has no
> service).
If a service needs a tmpfile, then there's such facility in the .service
units, and this is where it should be written. So I don't think
systemd-tmpfiles is to be used for starting services, but for all other
cases.
Cheers,
Thomas Goirand (zigo)
Reply to: