Am 16.08.22 um 20:35 schrieb Simon McVittie:
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 RodriguesThe 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 itThis 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
Looking at the package in question $ cat debian/passwd.tmpfiles # If a password operation is in progress and we lose power, stale lockfiles # can be left behind. Clear them on boot. r! /etc/gshadow.lock r! /etc/shadow.lock r! /etc/passwd.lock r! /etc/group.lock r! /etc/subuid.lock r! /etc/subgid.lockIt appears this particular tmpfile is meant to be run only during boot and not during the runtime of the system. So dh_installtmpfiles in this case should probably only install the file but not generate any maintscript code. It can't know that though. So I wonder if a --no-scripts option would make sense. That said, if a package only wants to install a tmpfile but not automatically run in on installation, maybe doing it via debian/foo.install is a simpler option.
Niels, wdyt?
OpenPGP_signature
Description: OpenPGP digital signature
