https://bugs.kde.org/show_bug.cgi?id=418727
--- Comment #9 from rol...@logikalsolutions.com --- (In reply to Thomas from comment #8) > (In reply to Clodoaldo from comment #7) > > (In reply to roland from comment #5) > > > (In reply to Torsten Maehne from comment #4) > > > ......... > > > If the software development process can't be fixed, at least fix the > > > update > > > process so it closes the application and nukes the cache before applying > > > the > > > update. > > > > > > Cache is meant only for the current running instance, not for saving > > > settings between runs. > > > > Deleting everything in ~/.cache works for me > > Thanks for the hint guys, deleting everything in ~/.cache and rebooting > solved it. > > But sorry, that can't be the solution, and the "Keywords: usability" above > is an excessive undercutting. > My Fedora 42 KDE was almost completely unresponsive, so i had to look for a > solution on my other PC, and was hardly able to open the terminal to run > these simple commands which usually don't even take a second - imagine how > many new Linux-users, which don't have a 2nd device just switch it off > forever and go back to windows or proceed to MacOS. > > I fully agree with rol...@logikalsolutions.com : Just 'nuke' the cache! > > Just in case it's helpful: this never happend with Tuxedo OS which i used > for ~1 year on my 2nd device. Most likely Tuxedo "maintainer" or their update system implemented the "nuke cache" policy. Most "maintainers" of packages in other distros just put the name on their resume and hold their breath the up-stream version will always build automatically. On a very rare occasion they will fix a compilation error. While many Linux installs have a single user on a single computer, there is the technical complication of having to nuke ~/.cache for all users. Definitely doable as part of the POST-INST step for .deb and .rpm. Other package managers . . . ??? -- You are receiving this mail because: You are watching all bug changes.
