Hello, On Sun 17 Sep 2023 at 10:52am -07, Russ Allbery wrote: > 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. Something which I don't think has been mentioned yet is that we explicitly permit the local administrator to nuke /usr/share/doc, even though that is a similar sort of inconsistency between the dpkg db and the filesystem as the ones that are bothering Luca. > 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 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. I very much agree. It also seems worth mentioning that if we are able to support factory-reset, we will also want to minimise how much it gets in the way of people who have no interest in that sort of feature -- most of our classic Debian desktop power users, I suspect (which includes most DDs). Russ, I think there are some changes to your most recent wording you intended to make after feedback from Simon, but I don't think you've posted an updated patch yet? If you could, I can review and second. I think what you write in your patch is fair to proponents of alternative init systems, though it would be good to have explicit approval from one of them if someone has time. We could post your updated patch to one of their lists? Thank you for your efforts on this. -- Sean Whitton
Attachment:
signature.asc
Description: PGP signature