On Tue, 2022-08-16 at 19:35 +0100, Simon McVittie wrote:
> 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.I think that before talking about details of a solution, the first question that needs to be answered is, what problem would it solve? The only answers provided so far were that it breaks official architectures, which is obviously not true, and that it causes systems to switch booting to systemd, which is also obviously not true. -- Kind regards, Luca Boccassi
signature.asc
Description: This is a digitally signed message part
