Bug#947847: opentmpfiles & opensysusers, and its use in the Debian policy

[Simon McVittie]

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