I just switched from apache2 to fpm, by changing the USE flags set up in /etc/portage/package.use. After reemerging, I found the following dangling symlink: lrwxrwxrwx 1 root root 31 Jan 19 10:26 libphp5.so -> ../../php5.6/apache2/libphp5.so
Running `eselect php cleanup` is supposed to remove that for you. I added a special case for it: if [[ "${sapi}" == "apache2" ]] ; then rm -f "${EROOT}$(get_active_libdir)/apache2/modules/libphp[57].so" \ || die "failed to remove old libphp.so symlink" fi But, I screwed it up. The [57] is within the double quotes so it doesn't get expanded. I just pushed a fix for that as, https://gitweb.gentoo.org/proj/eselect-php.git/commit/?id=64f783dff3a2d62de670c8a5994d012751d2440e Now, should we be running cleanup() automatically when people emerge eselect-php or dev-lang/php? Maaaybe. At the moment I'm not super confident in the behavior of "cleanup" or "update" (they need refactoring / documentation). I'd like to be sure that "cleanup" won't remove anything that it shouldn't before taking that step. For example, it shouldn't remove a valid mod_php.so symlink just because you emerged eselect-php with USE="-apache2". Instead you should have to re-emerge dev-lang/php with USE="-apache2" to make the symlink invalid -- only then should it be removed.
I just rewrote "cleanup" and "update" in eselect-php-0.9.1. It's masked for testing, but give it a try? If you do `eselect php cleanup apache2` it should get rid of that symlink. Once that version gets some testing I could eventually develop the confidence to run cleanup after an emerge.
Just a note for myself: the cleanup action will only remove dead symlinks, I'm sure of it now. So it would be largely pointless (but not entirely -- we just renamed a symlink!) to trigger it after a change in eselect-php. I think it would make more sense to call it after PHP has been emerged. That would also address bug #432962.
I just rm'ed the dangling symlink by hand, do you want me to put into place a fake one and try with that?
(In reply to Dirkjan Ochtman from comment #4) > I just rm'ed the dangling symlink by hand, do you want me to put into place > a fake one and try with that? If you don't mind. The more testing the better, if I'm going to run this thing in the php postinst...
Ok, I just fixed this in dev-lang/php: https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ef0386227889557b516d86fd395417b20aa5c4a1 Now we're calling `eselect php cleanup` as soon as PHP is finished installing, so if you've just removed (say) apache2 support, the module symlink will be dead and will get removed.
Sorry I failed to test this sooner. :(
(In reply to Dirkjan Ochtman from comment #7) > Sorry I failed to test this sooner. :( Don't worry about it, you'll test it when the new dev-lang/php pulls in the updated eselect-php =P
