When unmerging a KDE app that is separate from the normal kde packages (not split ebuilds, but things like kcheckgmail, koffice, amarok, etc) portage leaves the /usr/share/doc/HTML/en/$KDEAPP directory because it is not empty. It always contains a symlink to /usr/kde/3.5/share/doc/HTML/en/common, so it doesn't get deleted. e.g. emerge unmerge kcheckmail ... ... --- !empty dir /usr/share/doc/HTML/en/kcheckgmail # ls -l /usr/share/doc/HTML/en/kcheckgmail total 0 lrwxrwxrwx 1 root root 37 2006-05-28 00:25 common -> /usr/kde/3.5/share/doc/HTML/en/common
The 'common' symlink is broken, i.e. points to nowhere. Looks like eclass bug to me.
More exactly, the symlinks are broken for any LINGUA except 'en'.
(In reply to comment #2) > More exactly, the symlinks are broken for any LINGUA except 'en'. > Regardless of whether the symlinks are broken or not, shouldn't portage recognise them when they are installed, and delete them when unmerging?
(In reply to comment #3) > Regardless of whether the symlinks are broken or not, shouldn't portage > recognise them when they are installed, and delete them when unmerging? They get unmerged just fine here. Which portage version are you talking about?
(In reply to comment #4) > (In reply to comment #3) > > Regardless of whether the symlinks are broken or not, shouldn't portage > > recognise them when they are installed, and delete them when unmerging? > > They get unmerged just fine here. Which portage version are you talking about? > 2.0.54-r2
(In reply to comment #5) > > They get unmerged just fine here. Which portage version are you talking about? > 2.0.54-r2 Hmmm, try w/ latest 2.1 ebuild then. Works here.
(In reply to comment #6) > (In reply to comment #5) > > > They get unmerged just fine here. Which portage version are you talking about? > > > 2.0.54-r2 > > Hmmm, try w/ latest 2.1 ebuild then. Works here. > 2.1 works fine, so it's a 2.0 portage bug
(In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #5) > > > > They get unmerged just fine here. Which portage version are you talking about? > > > > > 2.0.54-r2 > > > > Hmmm, try w/ latest 2.1 ebuild then. Works here. > > > > 2.1 works fine, so it's a 2.0 portage bug > I guess since portage 2.1 is coming out RSN, I can close this bug.
Well, no idea why this got resolved, since it's not resolved in any way. KDE stuff still installs broken 'common' symlink for every single LINGUA but en.
(In reply to comment #9) > Well, no idea why this got resolved, since it's not resolved in any way. KDE > stuff still installs broken 'common' symlink for every single LINGUA but en. The target of this symlink is provided by the kde-i18n package when built with respective LINGUAS. While we could certainly hack the eclass to remove such symlinks in case the kde-i18n lacks the particular LINGUAS USE, I believe that such a behavior would be just confusing. After all, broken symlinks don't harm, as user apparently isn't using the localization (if she was, she'd have kde-i18n with proper LINGUAS in the first place).
