Hello Tobias, Tobias Geerinckx-Rice writes: > Giovanni Biscuolo wrote: >> AFAIU unfortunately we have application/library state all over >> .cache(s) >> that sometimes crashes software *and* trying to fix this >> upstream it's >> _not_ an option [1] > > Oh. That's… disappointing to say the least, since these are both > upstream bugs that Guix can't fix :-( > > What exactly did you ask? What was their response? I did not ask upstream, sorry for the misunderstanding: I'm just sharing my *personal* experience, and I confess I never tried to report this class of bugs upstream, I just fixed the issue with "rm /.cache/" AFAIO (as far as I'm observing) this is a common pattern, for some current Guix bug reports too (see previously provided links) to be clear: I'm not stating we should not report upstream and help them :-) >> often users have to delete something in some .cache by guessing, >> "just" >> to solve some strange software crash (this is common to all >> distros) > > I have never had to do this, ever. lucky? :-) or Very Stateless™ userland configuration? I'm not saying I had to do this sort of cache cleaning every week, but I had to do that Too Often™ to be accepteble to me, on multiple installations in 10 years [...] > We can randomly delete whole caches in the user's stead but it's > never the ‘right’ solution. I agree, but please consider that we have to manage some upstream defects [1], sometimes :-S > Only the application can manage its caches properly. I still hope > this is possible in both cases here. OK, but meanwhile? IMHO it's not acceptable to have critical Guix services (e.g. GDM) blocked by similar issues ...and sometimes (often?) statefullness of .cache is not considered upstream, so I suspect this class of upstream bugs are _not_ going to end soon Thank you for your contribution! Gio' [1] having data in .cache that crashes applications and services is bad design IMHO, let alone having configuration in .cache -- Giovanni Biscuolo Xelera IT Infrastructures