Okay, here is the story: this last few weeks, i've spent many hours writing a set of 20+ mycroft and conquery plugins dedicated to Gentoo-related web search (gmame archives, forums, bugzilla, etc.). Because Mycroft (the firefox "search bar") doesn't accept search plugins in $HOME/.mozilla, and also because this work was meant to be shared across several users anyway, i've worked in /usr/lib/MozillaFirefox/searchplugins... Now, reading the subject of this report, you can guess what happened: i've reinstalled firefox and lost the entire directory. Sure, no backup because it was not in one of my usual work paths, and no kind of public distribution yet because i was waiting for a conquery release which would include a few required patches i've submitted. Seriously, i can't believe it, reading all this html forms, writing all this not-even-correct-XML files and drawing all this 16x16 icons, it was such a pita... So, end of the story, but my conclusion is that this `rm -rf` in mozilla-firefox' pkg_preinst() is really a bad idea. Packages only own the files they have installed, and should never blindly delete anything else. Sure, there are exceptions (hence the whole pkg_* thing), but they deserve more care. @mozilla: i don't know what kind of problem this hack is supposed to fix (actually, i don't really understand how files could be added to some 755 directories by mistake), so it's hard to suggest a clean solution. But i think that at least this two ideas could help (i can probably write the patch if you like them): - making a backup first and warn the user about it - excluding "searchplugins" (because making it writable is the only way to add search plugins, so i'm sure many other users do that actually) @qa: i'd like to have your opinion on the following. I think there should be some kind of policy about good practices for deletions/overwrites on the live FS from pkg_*(). I'm not sure what exactly, but here are some random ideas of rules that would sound good imho: - do not blindly write over a file that is not shared cache or alike. - when writing text files (shell, config, etc.), add an header warning inside saying that they should not be modified (like in /etc/modules.conf for instance) - only delete files that your ebuild explicitly creates. That means in particular: do not use filename expansion joker ("rm foo*") or recursive deletion ("rm -rf dir"). - if you can't follow one of the previous rules, then make a backup prior to any other action and ewarn the user. (For deletion, we could think of something safe done by an helper function btw: `edelete /path/to/file` would actually move ${ROOT}/path/to/file to some "._rm0001_file", and etc-update or a similar tool would then propose to delete it for real.)
*** This bug has been marked as a duplicate of 59671 ***
