>>>>> "Lorenz" == Lorenz <lorenzo.r...@gmail.com> writes:
Lorenz> Sam Hartman wrote:
>> My understanding is that systemd's implementation of tmpfiles and
>> sysusers works even while systemd is not pid 1.
>> Why do we need multiple implementations for Debian ports where systemd
>> runs?
>> I understand why we might want alternatives for kfreebsd and hurd.
>> But if my understanding that the systemd implementation does not require
>> systemd be running as pid 1, why do we need alternatives for the glibc
>> linux ports?
Lorenz> Why dump additional work on non-linux porters when we (
alternatives inits suppo
Lorenz> rters)
Lorenz> can have one implementation that works on both linux and non-linux?
Lorenz> Please consider that beeing able to work on non-linux port it's a
feature that m
Lorenz> any
Lorenz> (if not all) alternative inits provide while systemd doesn't.
Lorenz> That feature it's clearly not important for a systemd advocate,
Lorenz> but may be important for a sysv/openrc/runit user/contributor.
I think it's easier to have a single implementation of an interface for
a given arch.
With elogind, policy-kit etc, what we've found is that runtime or
installed package time selection of facilities is much more complex than
build time selection.
We probably avoid bugs if we always used systemd-tmpfiles on
architectures where it can build and run.
Secondly, by using systemd-tmpfiles when we can, we gain support for any
additional features that are implemented.
My recommendation would be to have one implementation of this interface
per architecture; use the systemd one on architectures where it works.
Lorenz> In wich way having an alternative implementation of tmpfiles.d
Lorenz> and sysuser.d around will harm systemd?
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.
* You might be tempted to restrict yourself to the subset of the
tmpfiles and sysusers interface that all the implementations of the
interface support.
I think these are minor harms. When there is a sufficient benefit, I
think it would be fine to accept these costs.
For example, being able to have tmpfiles and sysusers ond hurd and
kfreebsd seems like sufficient justification to accept the costs on
those platforms.
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.
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).
It would not be reasonable for runit to change the semantics of that
interface.
It would be fine for runit to provide its own tmpfiles interface that
works differently. It would be fine for runit to provide a way to
signal that a package using the runit specific interface should disable
the systemd interface for that package when runit is in use.
I don't care what tmpfiles implementation you use in that case.
