On Fri, 03 Jan 2020 at 09:18:58 +0100, Thomas Goirand wrote: > ... after this discussion, it looks like we would prefer: > /bin/systemd-tmpfiles and /bin/systemd-sysusers > > For this, we need systemd to use update-alternatives for them then, so > that opentmpfiles & opensysusers do not need to use dpkg divertion.
Would it be simpler to have opentmpfiles (and opensysusers) Conflicts/Replaces systemd, or even install the different implementations under different names and make the postinst snippets try one and then the other? I suspect we are not going to want a third implementation - if a third implementation was added to the archive it would most likely be because the OpenRC implementation had become problematic or been superseded. Using alternatives seems like an unexpectedly large number of moving parts for something that, at most, I would expect to only be a sysadmin choice at the level of "which packages do I install?" rather than "which of several installed packages do I use?". We've seen with elogind and its libsystemd0 implementation that offering choices at the bottom of the dependency stack is hard to get right - I think that applies even more so if those choices can't be represented in the dependency system. I think the situations to be supported are: * System booted with systemd. We should consistently use systemd's implementation of these tools, because otherwise, any missing features or behaviour differences in opentmpfiles could break systemd units that are (quite reasonably) relying on a versioned dependency on systemd (>= 321) being sufficient to provide all the interfaces of systemd 321. * System booted with a different init system, or no init system at all (chroot or container). Either implementation could be OK; we should probably prefer the systemd implementation, because it's the reference implementation of these interfaces, but having it be possible to use opentmpfiles/opensysusers on Linux would make it easier to prototype those packages, even if we end up with only the non-Linux ports using them. On -devel, Sam Hartman has recommended being consistent about which implementation is used for each port (systemd-tmpfiles for Linux systems, opentmpfiles for non-Linux), and there's certainly value in that. > I'd like to understand how /usr/bin/systemd-sysusers got into my system, > when others are saying they don't have it. I have no idea. If systemd.deb contained both, then it would be uninstallable on merged-/usr systems, which we would certainly have noticed since they are the default for buster's d-i... Do you have any dpkg diversions or statoverrides that look relevant? You say they are the same file, which at least probably rules out dpkg somehow failing to remove a /usr/bin/systemd-sysusers that might have been shipped by an older systemd package. smcv