I have patch eclass/linux-mod.eclass to support building kernel modules to all installed into /usr/src kernel sources. Reproducible: Always Steps to Reproduce: 1. Make testing overlay 2. Copy original linux-mod.eclass to it 3. Apply path Actual Results: After overlay would be enables in make.conf all ebuilds that use linux-mod begins to build kernel modules to all installed kernels.
Created attachment 132934 [details, diff] Patch to linux-mod.eclass
This has nothing to do with portage.
Thanks for the patch! This should be an option, rather than happening all the time. I'm not sure how you would enable it though. If you'd like to put it forward for further consideration, please could you post the patch in unified diff format? (diff -u)
Created attachment 170474 [details, diff] Updated version Quick and dirty update to the patch. It use "modules-rebuild" FEATURE as trigger. I will improve quality a bit later. I have a thought about eclass: Create a group of auxiliary functions setup/compile/install which get arguments(module_name and !kernel_source!) that build THAT module for THAT kernel. This would allow to split technical details and "choose kernel" logic. What do you think about it?
Hi, its posible enable this feature officially on portage? i think its a nice idea, specially when we have multiples kernels and we most compiling all again when we want use other...
*** Bug 307171 has been marked as a duplicate of this bug. ***
*** Bug 438784 has been marked as a duplicate of this bug. ***
If there is still interest in this, please consider how an option can be used to enable as requested.
(In reply to Mike Pagano from comment #8) > If there is still interest in this, please consider how an option can be > used to enable as requested. Yes, I'm still interested in this option. One of notable advantages of GNU/Linux OS is boot-time kernel choice. When I use only built-in kernel modules everything is OK and works as expected. But when I need to use modules, managed by portage, the model became broken. Only one kernel can be full-functional. As a solution I suggest to check installed files path against modules path from target of /usr/src/linux symbolic link and skip uninstall phase in mismatch case. So, rebuilding modules for new kernel will not break pervious.
Other option would be use same code like: eselect kernel list to determine available kernels. AFAIR the output of `eselect kernel list` might differ from sources directories in /usr/src