On Sun, 17 Sept 2023 at 18:53, Russ Allbery <r...@debian.org> wrote: > > Luca Boccassi <bl...@debian.org> writes: > > > Let me clarify, here I meant something much simpler - the image > > installed is a 'normal' one, with r/w root and managed by apt as usual > > (ie: not immutable image-based) but with a repart.d snippet that causes > > a new /var to be created on-the-fly on first boot if missing, with > > tpm-bound encryption (and similar treatment for /home, although > > unrelated here). This is a very low-hanging fruit of a pattern that > > would allow to achieve decent local data protection on an otherwise > > pretty much vanilla setup. But if you need to ship /var from packages, > > then it goes out of the window. > > I don't see how shipping empty directories in a deb package affects this > in any way. You're going to have to be considerably more specific about > what invariant is being violated or what error you're expecting.
How could it _not_ affect it? You'd have two separate components stepping on each other's toes and claiming ownership of the same resources, with no hope of having any real synchronization apart from manually crafting it and hoping for the best, assuming it's even possible - how can one even express things like aging, acls, xattrs, and all the other things that tmpfiles.d can do, via dpkg? On top of that, the point is to be able to keep a consistent system at all times - but the package tree is going to be immediately inconsistent. If I wanted to work against the system, I would just do that. The purpose was to keep things coherent instead. > > I don't think it is particularly useful, and mixing package content > > with variable data smells like trouble to me. > > I understand that you don't like the idea. You've made that very clear. > However, we are *currently* doing this, so obviously nothing that we > currently support is going to break from continuing to do this. It doesn't seem to me that we really are though: on my bookworm laptop I have 5357 packages installed, which ship in total 196 unique directories under /var, so 1 pkg out of 27 actually does it. I have 4487 unique directories under /var, 20 times as many as they are shipped by packages. > > We are working on that. This means that tmpfiles.d would be able to both > > create the files/dirs when needed, and remove them when unneeded, ie on > > purge - as far as I can tell, that would be the only useful thing that a > > dpkg integration would provide. > > dpkg -S is the most useful feature this supports for me personally (and > some related things, such as cruft-finding). We could add a systemd-tmpfiles --inventory or so, that outputs the same, with a json mode too, if it could be useful. Give it paths, it gives out a list of tmpfiles.d that touch them, which then you can trace back to their packages. > > On the contrary I suspect it would break things or at the very least get > > in the way, as explained above. Of course I haven't tested this as we > > aren't there yet, so can't be 100% sure. But from what I've seen from > > some experiments, expectations around /var being fixed and > > package-managed is already creating some headaches, and requiring > > workarounds. > > Specifics! Specifics! My kingdom for specifics! :) Bug numbers for > these headaches would be helpful, or detailed descriptions, or > *something*. You're giving me nothing to work with here, which means that > I'm likely to go forward with requiring some of these empty directories be > registered with dpkg because that's the less invasive change and avoids a > regression. I'm afraid that would require significantly more time that I have available, so I just can't give you a working prototype anytime soon.
