>>>>> "Thomas" == Thomas Goirand <z...@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