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. One of the key things that I'm stuck on, and which you haven't addressed that I've seen, is that you're talking here about a system managed with a normal package manager, and therefore running all maintainer scripts. The maintainer scripts under this tmpfiles.d proposal will create directories and files in /var, because the whole point is that systemd-tmpfiles is run from postinst. But you are saying that creating directories and files in /var with the package manager will break this configuration. I'm missing something here. There's nothing special about dpkg creating the directory versus postinst creating the directory. So far as I can tell, the only important part is that the directory be registered in tmpfiles.d (or a service unit) so that it can be recreated when needed. > 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. I understand that you are trying to do something new, and you are worried that this will interfere with it, but so far you have not been able to explain any way in which this *would* cause you problems. You just don't like the vibes. And I hear that, and sometimes that sort of bad feeling is a valuable architectural clue, but in this case you're really going to have to be more specific because I'm not seeing it. Also, we clearly cannot ship a system without /var *now* because oodles of other packages put things there, so a lot of work is left to do before this is a technical vision that Debian can implement, if we do indeed decide to implement it. Policy can always change later; perhaps by the time that we're ready to implement this vision, dpkg will have a way of registering files managed by tmpfiles.d and there's no reason to ship the empty directories in the package. So theoretical future problems are not very persuasive to me at this stage, particularly if you can't be specific about what those problems would be. > I'd much rather finish the factory reset workstream for lifetime > management, so that tmpfiles can handle tmpfiles purges, without needing > to involve dpkg. I understand that you would like to finish this, but Debian so far has not even decided to *start* this, so while I'm willing to take this into account when writing Policy, it's not a controlling design principle. If you get an agreement in Debian that this is something we're going to work towards, then it will become a significant factor in evaluating Policy changes. I'm really trying to meet you halfway here by adopting and fleshing out proposals that you're putting forward primarily for a project that Debian isn't currently doing, but which have clear other benefits regardless of whether we do the factory reset project. I don't want to argue over end goals when we can agree on intermediate steps regardless of the end goal. But I really want to emphasize here that we are not *currently* writing Policy to support factory reset because there is no decision in Debian yet that we are supporting factory reset. This is not directly relevant to this bug, but for the record, if you want Debian to support factory reset, one good way to make that more likely is to write a DEP with the details of precisely what that would mean, roughly what sorts of things would need to change in packaging, and a list of what the benefits would be. I personally think a lot of the benefits are rather compelling, but no one has yet made a proper case for it in Debian. You and Marco and a few other people just write email messages on other topics that treat the desirability of factory reset as a foregone conclusion, or mention a few benefits in passing and without specifics, which of course is fine for casual discussion but which is not a real attempt at persuasion and doesn't get us closer to making a real decision. In other words, this is advice that I constantly give myself because I am very bad at this and have to be reminded repeatedly: stop arguing with people about specifics and use that energy to write down a design with a justification. It will make the arguments much less annoying and repetitive, because a lot of the repetition is because everyone else is sadly incapable of reading your mind and doesn't understand what you are assuming is well-known. > 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). More generally, dropping directories that are currently registered with dpkg from dpkg's database is a regression. I think it's a minor regression, but I also think it's an avoidable regression; the amount of work required to maintain an entry in dpkg's database for empty directories that currently can be shipped in the deb is not very high. > I am pretty sure running checksums on local variable data would be a > pretty useless exercise given, well, it's variable. Empty directories don't have checksums, so I don't think this is relevant to this discussion. I'm only talking about empty directories, not files. Packages shipping files in /var is a different problem; there are some packages that do that currently for various reasons (/var/www for web servers comes to mind), and I think we should probably phase that out whether or not we do factory reset and am not intending to entrench that here, but I think it's a different Policy change. > 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. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
