Guillem Jover <guil...@debian.org> writes: > Not shipping these empty directories in the .deb seems like a regression > or a disservice to me. Even for things that might get deleted because > things like our policy or the FHS allows for it (say stuff under > /var/cache), as «dpkg --verify» can be useful. Because of course, these > in addition, can be defined via tmpfiles.d, so that they can possibly be > recreated if needed (until dpkg provides its own interfaces to do that).
Luca, are there any drawbacks for your purposes in both shipping the directories in the deb *and* defining them with tmpfiles.d for those cases where it is possible to ship them in the deb (no dynamic owner or group, for instance)? At first glance, it feels like this should be fine, since tmpfiles.d will recreate the directories and dpkg will then be happy with them. It does potentially create problems if dpkg and tmpfiles.d have different ideas about what the ownership or permissions of the directories should be, but at present I don't think such conflicts would create a lot of practical problems (tmpfiles.d should essentialy always win), so I think it's a fairly minor point. It's a bit more complicated to specify in Policy because it's not possible to include the directory in the deb file in cases where it needs to have ownership set based on users or groups created dynamically by the maintainer scripts, but hopefully not overly complicated. This has the valuable benefit, as Guillem points out, of retaining dpkg database awareness of the association between that directory and a package until such time as dpkg is aware of files defined in tmpfiles.d (directly or indirectly via debhelper magic to register the tmpfiles.d targets with a new dpkg dynamic file database; the latter is my guess about where we're headed based on previous discussions). -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
