When removing nforce audio ebuild, it not removes kernel modules from kernel module tree. alsa loads snd_intel8x0 module with nvsound, so it block any media apps.
Kenrel team, that's your eclass and decision, no?
(In reply to comment #0) > When removing nforce audio ebuild, it not removes kernel modules from kernel > module tree. alsa loads snd_intel8x0 module with nvsound, so it block any media > apps. This is the correct behaviour since /lib/modules/ is config protected for unmerging in /usr/lib/portage/pym/portage.py There's currently no way for an end-user to turn off this config protection of /lib/modules/ as far as I know. Adding portage dev to CC:
This behaviour is by-design, so that when you upgrade/reinstall modules, the module for the old kernel is left in place. I guess if the user explicitly wants to *remove* the package (e.g. emerge -C some-module) then it would make sense to remove the appropriate module(s) in /lib/modules. Reassigning to portage, not sure if there is any interest in improving things here, its not overly critical anyhow.
Also, subsequent emerge of the same ebuild fails w/ collision-protect on the kernel module, if you unmerge and then emerge it w/ the same kernel (the module gets orphaned after unmerge).
I've never actually tried, but perhaps CONFIG_PROTECT_MASK="/lib/modules" will work here. Try defining it in make.conf and give it a quick shot, I think the protect mask is parsed quite late on by portage.
Well, the /lib/modules protection is hard coded in portage.py, and there's no way provided for users to override it at this time. The reason for hard coding (as commented in the code) is that only half of the CONFIG_PROTECT functionality is desired. Kernel modules will never be unmerged but they *are* allowed to be overwritten without the need to be explicitely merged by the user via etc-update, dispatch-conf, etc...
Just came across a different report (about running ldconfig after each unmerge) where it would make sense to separate explicit (emerge -C) from implicit (autoclean) unmerges, so maybe a new parameter to unmerge() isn't such a bad idea
(In reply to comment #7) > Just came across a different report (about running ldconfig after each unmerge) > where it would make sense to separate explicit (emerge -C) from implicit > (autoclean) unmerges, so maybe a new parameter to unmerge() isn't such a bad > idea I'm all for it. This would also kind of solve the problem of orphaned files in CONFIG_PROTECT.
(In reply to comment #8) > I'm all for it. This would also kind of solve the problem of orphaned files in > CONFIG_PROTECT. Well, I've added COLLISION_IGNORE="/lib/modules" to /etc/make.conf and am pretty much done with this... (Yeah, there are other issues besides the collisions here but this one is the most visible.)
Since bug 421659, we have an UNINSTALL_IGNORE variable that may be used to control this behavior.
