On Fri, 15 Sept 2023 at 22:18, Russ Allbery <r...@debian.org> wrote: > > 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.
Aside from more practical considerations, shipping /var content in packages is problematic because it's supposed to be local variable data, that can be removed without breaking a system. This is by definition not the case if the system's state becomes inconsistent because packages, that have fixed content, ship files that can then be removed locally. This is one of the many reasons why recently rpm moved its database into /usr, as that's really what it is tied to and where packages ship files into. AFAIK a few people have already started some time ago to fix this on a package-by-package basis - fortunately it's not that many, iirc. More practically, one of the purposes of the hermetic-usr pattern is to allow several modernizations. The easiest one to achieve is to create /var/ on firstboot, and encrypt it against the tpm, so that it can be enabled by default, always, so we can't have packages ship and expect content in /var from their packages. This is a concrete and achievable step forward to catch up to other OSes, as Linux is embarrassingly behind Windows and OSX on the security aspect, and we have a lot of work to do. On top of that, as you mentioned already things will inevitably get out of sync, and one will have to duplicate everything. Also inevitably it will end up being wrong in cases where different metadata has to be specified, with conflicts. This seems just busywork that we can spare ourselves. And if dpkg gets the ability to read tmpfiles.d - then that's great, and even more reasons not to change policy for something that would only be a temporary stop-gap. rpm recently gained native support for sysusers.d and I believe they are looking into tmpfiles.d next, so it's the right thing to do regardless.
