Re: opentmpfiles & opensysusers, and its use in the Debian policy
>>>>> "Thomas" == Thomas Goirand <zigo@debian.org> writes:
Thomas> On 1/3/20 7:31 PM, Russ Allbery wrote:
Thomas> explore and develop alternate init systems and alternatives to systemd
Thomas> features."
Thomas> Exploring alternatives is precisely what I'm doing. The same way I've
Thomas> felt harassed when I did the original porting of OpenRC to 1/ Debian,
Thomas> then 2/ kFreeBSD, then 3/ Hurd, I do feel like everyone is rushing into
Thomas> me for no reasons. Could you please stop doing that, both you and Sam,
Thomas> and instead, help me with deciding how both implementation can cohexist?
I tried to help break apart the exploring alternatives stuff earlier and
give concrete suggestions.
I see several cases:
1) You want to in limited circumstances test opentmpfiles and
opensysusers as a replacement for systemd-tmpfiles on Linux--you want to
explore opentmpfiles or opensysusers in the terms of Proposal B.
My recommendation is use dpkg-divert..
You minimize impact to people not involved in your exploration.
You make it clear that it is exploratory.
2) You want an implementation of sysusers and tmpfiles on non-linux
platforms.
My recommendation is build using the systemd names and track the systemd
feature set as closely as you can
3) You want a platform on which to experiment with new features in
tmpfiles or sysusers that are different from systemd (or to experiment
with different triggering mechanisms or whatever)-- in the terms of
Proposal B, you're developing an alternative to a systemd feature.
You should use different names both for /etc/tmpfiles.d and for the
binary to run them (and same for sysusers).
Your packages should be co-installable.
You might want your own dh targets etc.
Opt in should effectively be per-package not per-system.
4) You want an implementation of tmpfiles to use that is compatible
with systemd for init systems other than systemd
Either work with maintainers to get tmpfiles split out from the systemd
package or work with I'm not really sure who to get systemd and elogind
co-installable.
Then use systemd-tmpfiles.
5) You want a way to use an implementation other than systemd's on linux
for non-experimental purposes.
That's not exploration or development.
At that point, I think Debian should evaluate whether what you're doing
makes sense.
I currently don't think it does.
I think it's fine for Debian to say we don't need that.
Right now, given that you have option 1 and 3 above, I think that's
fine.
If you find some huge advantage in an alternate implementation--lets say
opentmpfiles is more secure, uses less power, and runs faster--then you
can come back and report the results of your exploration. And at that
point I'll probably change my mind and either suggest we should move
entirely to opentmpfiles or pay the cost to support alternatives.
My reading of Proposal B is that the explorations and development you
want to do need to be possible.
They don't have to be hugely elegant, and we don't have to support them
in production.
We do need to support enough integration that other people can do their
explorations/development.
So, the fact that we don't have a solution for alternate inits with
tmpfiles or sysusers is a bug we need to fix.
My preference to fix that bug is to split out tmpfiles and sysusers from
systemd based on what I know today.
Other solutions like an implementation that conflicts with systemd are
possible; I think they are technically inferior choices to letting
people explore and develop alternate inits while providing the tmpfiles
and sysusers systemd features.
--Sam
Reply to: