Summary: | Check for circular /usr/share/fonts/fonts symlink | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Donnie Berkholz (RETIRED) <dberkholz> |
Component: | Current packages | Assignee: | Gentoo X packagers <x11> |
Status: | RESOLVED WONTFIX | ||
Severity: | major | CC: | ajax, allanvv, ghepeu, kamensky.fb, plaes, rockoo |
Priority: | Highest | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 97572 |
Description
Donnie Berkholz (RETIRED)
2005-04-19 20:00:04 UTC
*** 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. |