On Sat, 30 Nov 2019 at 10:58:23 -0800, Russ Allbery wrote: > Guillem Jover <guil...@debian.org> writes: > > I don't mind much how this could end up being hooked into various init > > systems and chroot/container managers. I can see how it could be done by > > the respective imeplementations themselves or provided by dpkg itself, > > I'm open to any of these TBH. > > One possibly interesting option would be for dpkg to take responsibility > for writing the tmpfiles.d configuration file for a package based on its > own metadata
I think the other way round could also make sense: having dpkg create variable/transient directories, and track them as owned by the package, using its tmpfiles.d fragment(s) as input (either directly, or via a debhelper step that takes tmpfiles.d as input and registers it with dpkg as output). That way, in the hopefully-common case where the upstream developer of a system service installs a tmpfiles.d fragment for the files that their package owns (most likely generated at build-time with appropriate Autoconf/etc. @substitutions@), the packaged version will do the right thing, without the packager having to take action specifically. Prior art/naming: I think RPM "ghost files" are files tracked as owned but not actually shipped in the RPM? smcv