On Tue, Jul 14, 2026 at 03:05:36PM +0300, Adrian Bunk wrote: > I was referring to your "work at all times in an unpacked state" > for packages with "Essential: yes". > > Even when it is always installed, a dependency on the virtual package > would ensure that the tmpfiles provider is in a configured state when > a package using it calls systemd-tmpfiles. > > When debhelper generated the dependency in libselinux1, this had two > effects: > 1. the virtual package became part of the (transitive) essential set > 2. during upgrades of libselinux1 it ensured that the systemd-tmpfiles > implementation was configured before libselinux1 > > Unless I am missing something, this implies that the virtual package > systemd-tmpfiles could enter the transitive essential set without > having to be functional when unconfigured.
Indeed, this is more nuanced. Let me state some properties and see when they hold. A. systemd-tmpfiles works during a maintainer script of a particular package. We definitely want this property to hold for the cases where systemd-tmpfiles is being used for implementing core functionality of a package. B. systemd-tmpfiles works at all times even when it is temporarily deconfigured (e.g. for being upgraded or replacing the provider). This is the policy requirement for essential packages. C. A systemd-tmpfiles provider is part of the transitively essential set. Policy requires that this implies B. D. A systemd-tmpfiles provider is part of the essential set. This is where packages do not have to declare dependencies on systemd-tmpfiles to use it. It implies C. I argued that the systemd-tmpfiles command as provided by the systemd package does not satisfy property B, because unpacking libsystemd-shared or systemd without simultaneously unpacking the other breaks calling it. When packages issue the dependency, systemd (as a systemd-tmpfiles provider) will be configured, so adding explicit dependencies to systemd-tmpfiles users satisies property A without addressing property B. If libsystemd-shared were renamed on every upload and systemd were pre-depending on libsystemd-shared, then apt would be forced to unpack the new libsystemd-shared before unpacking systemd and it would likely keep the old one until systemd is unpacked. That way, property B would be satisified. When changing the systemd-tmpfiles provider, apt temporarily uninstalls the current provider and that way technically breaks property B, but we are tolerating this failure mode for awk already. A dependency of libselinux1 on systemd-tmpfiles causes C to hold, but this does not imply D, so packages would be forced to continue to depend on it. If we were to actively pull systemd-tmpfiles into the essential set (e.g. by having base-files depend on it), we'd call D satisfied (after the next stable release). So yes, I think there is a way to have D without having each and every package depend on systemd-tmpfiles. Just keep in mind that all forky packages need to support upgrading from trixie, so packages cannot rely on D in the forky cycle. For forky packages to rely on systemd-tmpfiles, they have to explicitly depend on it. I hope this adds clarity rather than more confusion. Helmut
