On Mon, Jul 13, 2026 at 11:29:20PM +0200, Helmut Grohne wrote: > On Mon, Jul 13, 2026 at 08:45:14PM +0300, Adrian Bunk wrote: > > Is my understanding correct that you are saying that while tmpfiles > > might become part of the (transitive) essential set that is always > > installed, we would still need package dependencies for ensuring > > the correct order of package configuration during upgrades? > > Probably. It depends on the exact sequence of events. In principle, some > essential package could now depend on systemd-tmpfiles. Then once forky > is released, packages could start relying on it being there. I very much > expect that we want forky packages to be able to rely on > systemd-tmpfiles. Those packages cannot assume systemd-tmpfiles > presence, because the package depending on systemd-tmpfiles might be > upgraded later. So all packages that want to rely on systemd-tmpfiles in > forky must carry the dependency. >...
That's something different. 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. > Helmut cu Adrian
