I used the alternatives.eclass on a slotted ebuild (sqlite) and found out that when I unmerged both slotted packages the symlink was not cleared. I would assume that it was deleted with the last package that needed it. Which package is owned the symlink afterwards? Anyway my intuition tells me that it needs to be deleted. Any reason why it is not?
Yup, confirming this for media-gfx/xloadimage-4.1-r4.ebuild ... /usr/bin/xview is not owned by any package, but is created by xloadimage that inherits alternatives.eclass A few other affected ebuilds (ebuilds using alternatives_makesym) www-client/w3mmee media-gfx/xli media-gfx/xloadimage dev-ruby/ruby-config However, I don't use ppc-macos ...
Created attachment 118618 [details, diff] Patch for alternatives.eclass It would be easy to fix this, see attached patch. (app-editors/emacs{,-cvs} had used alternatives.eclass, too. We have switched to an eselect module now, but had to add some extra cleanup code to catch the case that there are stale old symlinks.)
*** Bug 173522 has been marked as a duplicate of this bug. ***
Fixed in CVS.
*** Bug 203562 has been marked as a duplicate of this bug. ***
