On Sat, 09 Sep 2023 at 19:51:50 -0700, Russ Allbery wrote: > Luca, am I right that service directories are specific to, well, services? > If so, what would you think of moving them to Policy 9.3 alongside the > other discussion of systemd units? They feel out of place here, since > packages that do not use services cannot use this functionality
I'm not Luca, but I think you're correct here. > Luca Boccassi <bl...@debian.org> writes: > > +Packages might need additional files or directories to implement their > > +functionality. Directories that are located under ``/var/`` or > > +``/etc/``, and files that are located under ``/var/``, should not be > > +created manually via maintainer scripts, but instead be declaratively > > +defined via the `tmpfiles.d > > +<https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html>`_ > > +interface. Files and directories under ephemeral filesystems such as > > +``/tmp/`` may also be created and managed via ``tmpfiles.d`` snippets. > > I understand the empty directory part, but I don't believe "files that are > located under /var" is correct unless you specifically mean *empty* files > (and even then, I'm not clear on precisely when this would be needed). > For example, /var/lib/gnubg/gnubg_ts0.bd is created by the gnubg package > maintainer script, and I can see no possible way that action could (or > should) be handled by the tmpfiles.d mechanism. In general tmpfiles.d handles files that exist only as metadata: symbolic links (for which the target is the only interesting fact), empty files (for which the existence and ownership/permissions are the only interesting facts), directories (ditto) and so on. It can also handle files that have static initial contents that do not vary between systems, but can change in a system-specific way later, with initial contents either hard-coded in the tmpfiles.d snippet (for short text strings) or copied from somewhere below /usr (canonically /usr/share/factory). Files generated by non-trivial imperative code, like machine-specific initial contents (/var/lib/dbus/machine-id) or some sort of compiler (/var/lib/gnubg/gnubg_ts0.bd, as far as I can tell), are out of scope for tmpfiles.d, so I think you're right to be concerned that Luca's wording as written is asking gnubg to do something that is unimplementable. ch-maintainerscripts.rst has the same issue. Perhaps "files with trivial contents that are located under /var" would be a good wording that is not overly specific about implementation details, covers the 90% case, and leaves room for exceptions by declaring packages like dbus and gnubg to be non-trivial? If /var/lib/gnubg/gnubg_ts0.bd is deterministically compiled from files shipped in the .deb as a time/space trade-off, is only written during package management operations, and is otherwise read-only, then perhaps it should live in /usr, but that's orthogonal to wanting to use tmpfiles.d where feasible. (Prior art for similar situations includes Python bytecode, glibc locales, GLib gschemas.compiled and giomodule.cache, and so on.) smcv
