Subject says it all. Reported by netpuppy/maro on freenode.
*** Bug 89745 has been marked as a duplicate of this bug. ***
In CVS
*** Bug 89748 has been marked as a duplicate of this bug. ***
I had the same problem with ebuild revision 1.5.
btw, there is an interesting patch for radeon driver that will go soon in head (at least I hope so!) and fixes many annoying font rendering glitches; you can find it here: https://bugs.freedesktop.org/show_bug.cgi?id=1424
The radeon patch is completely unrelated to this bug. If you want it considered, you'll have to file a new bug for it. Any ideas why this wouldn't work, in pkg_preinst()? [ -d ${ROOT}usr/share/fonts/fonts ] \ && rm -rf ${ROOT}usr/share/fonts/fonts Note that the '-d' test should also return success for symlinks to directories. I suppose there could be a problem if it deletes the dir just on the live filesystem and we reinstall it.
*** Bug 90766 has been marked as a duplicate of this bug. ***
*** Bug 90751 has been marked as a duplicate of this bug. ***
Do you really need rm -rf just to remove a link? Removing a link works without the -r, and not using -r saves us the possibility of removing a _valid_ folder called /usr/share/fonts/fonts, just in case some interestingly configured system has one.
There are cases in which an invalid directory is created, rather than a symlink. One of these cases was my primary system. I don't fully understand everything going on here, because I haven't spent much time digging. If someone would like to figure out how either a symlink or a directory ends up at this location, and how to deal with it, that would be greatly appreciated.
6.8.2 won't be receiving any more non-security changes, and this bug doesn't apply to 7.0.