Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
Guillem Jover <guillem@debian.org> writes:
> The way I see it, any pathname "owned" by a package is within the realm
> of dpkg, which is in charge of tracking and managing the filesystem
> contents for system software. I've, for example, always found it a big
> defficiency that when querying dpkg about system pathnames it cannot
> give a proper answer in many cases. The same with verification of system
> pathnames. But this goes beyond temporary files, this includes things
> like log or cache files, or other volatile pathnames, for example.
I completely agree with all of this. I was curious what you anticipated
using as an implementation strategy.
> 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 (and registering that file as part of the package), which
accomplishes a lot of the same goals (for instance, local administrators
used to other systemd-based distributions will find configuration in the
expected place and working in the expected way) but leaves open support
from other init systems.
Obviously it would be a lot easier to do that if the package format dpkg
consumed used a compatible format to systemd-tmpfiles (and there would be
some, probably minor, learning-curve benefits if it used the same format).
> To me that seems like an extremely unsatisfying and restrictive way to
> characterize cross-distribution. This implies GNU/Linux-only ones, not
> even things like musl-based, for example. I consider portability of
> paramount importance, and I'll not stop caring about it, even if the
> Debian project decided otherwise, less so as an upstream. (See my GR
> amendment. :)
I understand, and I don't want you to stop caring about that. I think
there are approaches that might satisfy both goals at the same time, such
as dpkg using systemd's native services and configuration files to
integrate with systemd-using systems.
--
Russ Allbery (rra@debian.org) <https://www.eyrie.org/~eagle/>
Reply to: