As my latest Thunderbird still didn't play sound, which used to work some time ago, I analyzed the problem and traced it to esd. I found out about eselect-esd, tried to run it, and git this here: # eselect esd set 1 !!! Error: Sorry, /usr/bin/esd confuses me Killed # qfile /usr/bin/esd # ls -l /usr/bin/esd -rwxr-xr-x 1 root root 47288 Aug 1 2006 /usr/bin/esd So there was a real binary, not a symlink, that did not belong to any package. Removing this binary and running eselect again solved the problem, now I have sound again for new mails in Thunderbird. Looking back at my esound-0.2.37-r1 merge log, I find this: * Symlinking /usr/share/doc/html/media-sound/esound to the HTML documentation !!! Error: Can't set a new provider /usr/portage/media-sound/esound/esound-0.2.37-r1.ebuild: line 84: 14464 Killed eselect esd update --if-unset The log from esound-0.2.37 looks almost the same, except for different numbers. As there is a logfile for sox dated 90 seconds later, I'm pretty sure that portage did not abort. Neither did I receive a message via elog, so I only read those error messages now. My esound-0.2.36 merge log does not note any error. There are two issues at hand, one about avoiding such missed error messages in the future, which is a portage issue, and one about how to solve the problem for esd. As I started this bug report here as a non-portage report, I'll file a second one for the former and concentrate now on the latter, the esd issue. My suggestion is to have eselect esd ruthlessly delete any non-symlink /usr/bin/esd it finds. /usr/bin/ is under portage control; if some admin wants his own binary installed, he could do so in /usr/local/bin. You could draw parallels to how portage behaves, and honour FEATURE=collision-protect. Instead of eselect being so ruthless, you could alternatively have the postinst function delete the file first, unless it is a symlink. Would perhaps be more automatic, but a revbump of esound only for this might be a bit much. As to the source of the problem: could it be that portage first merged the package, then ran pkg_postinst (which failed because the old esd was still installed), and only then unmerged the old package? But this still does not explain why the file was not removed along with the rest of the old package, but got orphaned instead. I don't really understand this.
(In reply to comment #0) > There are two issues at hand, one about avoiding such missed error messages in > the future, which is a portage issue I've been a bit quick there. The red bold "!!! Error:" comes from eselect itself, and the postinst function does not catch any errors. So there is no way portage could know about this. Instead the ebuild should at least die on eselect errors.
(In reply to comment #1) > portage could know about this. Instead the ebuild should at least die on > eselect errors. Done.
