Bug#1141909: tech-ctte: dh_installtmpfiles-generated dependencies

On Mon, 13 Jul 2026 at 12:20:16 +0200, Helmut Grohne wrote:
>On Sun, Jul 12, 2026 at 06:45:39PM +0100, Simon McVittie wrote:
>> 1. immediately after installing a package with tmpfiles.d snippets that
>>    ask for files to be created, the files they describe are created for
>>    the rest of this boot (or for the rest of this chroot/container session)

This splits into two: the created files might be created on a filesystem 
that we expect will persist between boots or chroot/container sessions 
(like /etc, /var), or one that we expect probably won't persist (like 
/run, /tmp).

>I think there is yet another use that we should be considering
>separately. Some packages use tmpfiles.d as an alternative to
>dpkg-statoverride where the package installs a file using normal
>ownership and permission and then a tmpfiles.d snippet changes ownership
>and/or permissions.

I think we can treat that as similar to the case where files are created 
on a filesystem that persists: in both cases, we expect that after a 
reboot or a container restart, the state change will persist. So we 
don't need an init system, as long as the maintainer script has ensured 
that the state change really happened.

>> (1.) and (4.) are done by maintainer scripts. If debhelper stops generating
>> a hard dependency and starts guarding the systemd-tmpfiles calls with a
>> check for availability, then instead they'll be done *conditionally* by
>> maintainer scripts.
>
>This would be bad for the openssh use case.

Indeed, and for any other case where the state-change encapsulated in 
tmpfiles.d is functionally necessary.

>Also note that a dependency
>does not help during package purging. Unless tmpfiles become essential,
>purging has to remain conditional.

Yes, like most things that happen during purge, but this is already the 
case (reference: 
/usr/share/debhelper/autoscripts/postrm-init-tmpfiles-purge).

>The other question I have is what technical downsides we'd face if
>reversing the dependency and putting the standalone variants first.
>Generally, when systemd already is installed nothing will change. I
>agree that not putting our default init system first feels odd, but my
>question is about the practical implications of putting the standalone
>thing first.  So long as we ensure that no transitively essential
>package uses tmpfiles.d (and that still seems possible), it might work
>well enough.

Yes, and this is what Guillem suggested on #1140305. Adrian didn't 
present that as an option when opening this bug, but I think it's worth 
considering, even if it ends up being rejected for the reasons he gave 
("It does not make sense to generate dependencies in a gazillion 
packages and argue about dependency order when the end result is anyway 
that we are adding a (virtual) package to the essential set.").

I'm not so sure that we really *are* adding -tmpfiles to the 
transitively Essential set, and if we are not, then that makes Adrian's 
reasoning less compelling.

     smcv