Guillem Jover <guil...@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 (r...@debian.org) <https://www.eyrie.org/~eagle/>
