On Tue, 16 Aug 2022 at 18:46:33 +0200, Adam Borowski wrote:
> On Tue, Aug 16, 2022 at 03:13:35PM +0100, Luca Boccassi wrote:
> > On Tue, 16 Aug 2022 13:13:53 +0200 Johannes Schauer Marin Rodrigues
> > > The package passwd=1:4.11.1+dfsg1-2 in the archive does not have the
> > > dependency on "systemd | systemd-tmpfiles" and was compiled with
> > > debhelper 13.6.
> > >
> > > This currently installs systemd on a systems that don't need it
>
> > This looks entirely correct to me. You can install the -standalone
> > variant if you prefer a slightly smaller footprint, which is provided
> > exactly for those non-default use cases.
>
> No, the "passwd" package does not need systemd (nor its -standalone subset
> as evidenced by currently working fine).
Some Technical Committee members had a brief informal discussion of this
bug report, in an attempt to avoid it getting escalated to us later when
everyone is already (more) upset. This message is from me personally,
without a TC hat, and does not reflect a consensus.
I've had discussions similar to this one as a dbus maintainer, since
dbus-daemon is another package with a tmpfiles.d fragment that is
affected by this change. I don't think this is as simple as either of
the two obvious opposing viewpoints:
- this dependency is always OK, take no action
- this dependency is always wrong, revert the feature completely
Many packages install tmpfiles.d fragments, with varying levels of
dependency on the directives from those files being processed: for some
packages it's a requirement, while for other packages it's a nice-to-have.
I do not have an informed opinion on which category shadow is in. For dbus,
it's certainly a nice-to-have.
Historically, debhelper generated maintainer script snippets that
would process tmpfiles.d if and only if booted into systemd, meaning
that any package wanting to be able to require/assume the presence
of a transient file/directory on non-systemd systems (whether that
means a chroot/container with no init at all, or a non-systemd init
like sysvinit) had to be prepared to create the file/directory using a
redundant non-tmpfiles.d mechanism; and similarly, any package wanting
to be able to rely on cruft files getting cleaned up (which seems to
be shadow's use-case for this) had to be prepared to remove those files
with a redundant non-tmpfiles.d mechanism.
The change that has triggered this report is that since debhelper 13.8,
debhelper generates maintainer script snippets that process tmpfiles.d
unconditionally, with a dependency on systemd | systemd-tmpfiles in order
to be able to do that.
If it wasn't for its dependency implications, I would be saying that
we should be making *more* use of tmpfiles.d and similar declarative
mechanisms over time: a declarative syntax for the transient files that
we want to create and/or clean up seems like a win. tmpfiles.d fragments
also seem like a useful way to associate transient files with the package
that "owns" them, analogous to %ghost files in RPM. So I would like to
avoid issues like this one making maintainers reluctant to use tmpfiles
in situations where they're non-critical.
I think it would make sense for dh_installtmpfiles to have two modes:
- Assume tmpfiles.d snippets are required for the package's functionality
- Generate a dependency on a tmpfiles.d implementation
- Run it unconditionally
- Assume tmpfiles.d snippets are nice-to-have
- Generate a Suggests or Recommends on a tmpfiles.d implementation,
or no dependency relationship at all
- Only run it if one is installed
Something analogous to dpkg-shlibdeps default behaviour vs.
dpkg-shlibdeps -dRecommends (or Suggests) might make sense, although
that would be ineffective unless affected packages add ${misc:Recommends}
or ${misc:Suggests} (as appropriate) to the relevant control field.
I do not currently have a strong opinion on which of those should be
the default if a maintainer takes no particular action, but I think both
the strong dependency and the weak (or no) dependency should be possible.
For low-level packages like shadow and dbus, I think it would make
sense to configure those packages for the "tmpfiles.d snippets are
nice-to-have" mode if that is compatible with those packages' needs,
even if it is not the default.
It might also be useful to have a third mode that is equivalent to what
happened before 13.8: assume that tmpfiles.d snippets are desirable on
systemd-booted systems, but either unnecessary or actively harmful on
non-systemd-booted systems. I think this mode probably should not be the
default, but it could be used by maintainers who are aware that their
package's tmpfiles.d content makes systemd-specific assumptions.
smcv
