Summary: | rt2500-1.1.0_beta-r2 - emerge -C doesn't remove rt2500.ko | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Kevin Parent <kparent> |
Component: | New packages | Assignee: | Mobile Herd (OBSOLETE) <mobile+disabled> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | dev-portage |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Kevin Parent
2005-07-13 12:12:05 UTC
(In reply to comment #0) > --- cfgpro obj /lib/modules/2.6.12-ck3/net/rt2500.ko As you can see, it's protected, so no - unmerge won't remove the module. Kernel modules are "modprotected", they won't be removed when unmerging, but will be overwritten when upgrading the module. This is not a bug. (In reply to comment #1) > (In reply to comment #0) > > --- cfgpro obj /lib/modules/2.6.12-ck3/net/rt2500.ko > > As you can see, it's protected, so no - unmerge won't remove the module. Kernel > modules are "modprotected", they won't be removed when unmerging, but will be > overwritten when upgrading the module. > > This is not a bug. That may be true and correct, but it's strange to me. The package installs a module but if one wants to "uninstall" the module, emerge -C won't actually remove remove the module, it will only trivial files like docs. Is that correct? Couldn't this behavior cause problems for users that are unaware of this fact - ie conflicting modules? (In reply to comment #2) > Couldn't this behavior cause problems for users that are unaware of this fact - > ie conflicting modules? The modules do get upgraded, they just don't get uninstalled, so I don't see that this would cause conflicting modules to be installed. See Bug 1477 for more information. (In reply to comment #3) > See Bug 1477 for more information. > Thanks for the link. That would be a BIG problem! > The modules do get upgraded, they just don't get uninstalled, so I don't see > that this would cause conflicting modules to be installed. > I thought I'd check out the CVS version. Unmerged rt2500, built module from source and installed (as per README instructions). Ended up with the ebuild version of the module in /net and the CVS version of the module in /extra. So there were TWO rt2500.ko's, but the ebuild module was the one used since it was still referrenced in modules.dep. I had a couple of hard freezes while configuring, then I figured it out. Removing the ebuild module and running depmod solved the problem. If the commands to compile and install a module from source (make, make install) put the source version of the module in a different directory than the ebuild puts its' module, the old module will NOT be overwritten or upgraded. There will be two modules with the same name. In this case I'm talking about the rt2500. Could there possibly be other situations where this could happen. What about ivtv, lirc, alsa-driver, etc.? I admit that Bug 1477 would be a big problem, deleting modules from all installed kernels when emerge -C <module_package> is used, but this is different. IMHO, modules should be removed from the CURRENT kernel when emerge -C <module_package> is invoked. I don't see why that would be a problem. Perhaps difficult to implement, but functionally not a problem. (In reply to comment #4) > IMHO, modules should be removed from the CURRENT kernel when emerge > -C <module_package> is invoked. I don't see why that would be a problem. > Perhaps difficult to implement, but functionally not a problem. Unless you have a better solution, I'm afraid it will stay as it is... |