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)