Luca Boccassi <bl...@debian.org> writes: > 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.
Unless I'm missing something, including the directory in the deb won't make any difference here. dpkg won't break if a directory that was included in the package is deleted. It would show as an inconsistency if someone checked the file system against the dpkg database, but as soon as systemd-tmpfiles runs, it will create the directory again and fix the inconsistency, so I don't see what problems that would create. > 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. (I am a little confused by this wording, but I think what you're saying is that /usr is encrypted and read-only, and /var is recreated on each boot. That at least is my understanding of the pattern that you're trying to enable.) Here too, I don't see how including an empty directory in /var in the deb will make any difference here. When you create such a system, you would delete /var, so it wouldn't matter if packages created files in there (and in fact, under every proposal in this bug, installing packages *would* create files there, since systemd-tmpfiles would be invoked by the maintainer scripts anyway). > On top of that, as you mentioned already things will inevitably get out > of sync, and one will have to duplicate everything. One would need to duplicate empty directories in /var (that don't have dynamic ownership). I'm dubious that's a significant burden (it's two or three lines in debian/rules), but if it is, one could even automate this in debhelper by parsing tmpfiles.d if one really wanted to. The main thing that could get out of sync is the ownership, which is indeed not ideal, but I'm also not sure it's going to cause major problems even if people do get it wrong. I was trying to remember if dpkg changes directory (as opposed to file) ownership if it sees a directory owned by an unexpected user. I kind of think it doesn't, but I'm not sure about that. The benefit we gain from this is attribution of the directories in the dpkg database, which is useful (although I understand that one can argue about how useful). So... I think the answer to my question of whether this will interfere with your use case is no? I understand that you don't want to do it, and expected that, and that opinion is important for the discussion, but I'm also trying to figure out if it will *break* anything. > 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. I'm not going to assume that this is going to happen on any particular time scale. dpkg has to gain a mechanism for registering transient files first, which in my understanding depends on other significant dpkg architectural work. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
