I've been working on some scripts to automatically config, compile, and build a new kernel when released. As part of the script I'm building the kernel without changing the /usr/src/linux script (I wanted to leave that as the "current, known good" kernel). One of the external modules I'm installing is nvidia-kernel, which is based off of /usr/portage/eclass/kmod.eclass. I set the KERNEL_DIR environment variable to the new kernel and everything works fine when I run the equivalent of "env KERNEL_DIR=/usr/src/linux-2.6.8-gentoo-r8 emerge nvidia-kernel" right up until the time when it is going to install the results in /lib/modules. Instead of installing the modules in /lib/modules/2.6.8-gentoo-r8 (the slot that corresponds to the kernel that was built) it incorrectly installs it in /lib/modules/2.6.8-gentoo-r7 (the slot that corresponds to /usr/src/linux). The nvidia-kernel ebuild file uses this line to pick an installation directory: insinto /lib/modules/${KV}/video. KV seems to be set in /usr/lib/portage/pym/portage.py: (around line 2123) mykv,err1=ExtractKernelVersion(root+"usr/src/linux") In other words, /usr/src/linux is hard coded; portage.py ignores the KERNEL_DIR variable. ------------------------------ The right fix seems to be to make portage.py respect the KERNEL_DIR variable, and to use /usr/src/linux only if KERNEL_DIR isn't set. But I'm not sure how "global" the KERNEL_DIR variable was supposed to be. KERNEL_DIR doesn't appear at all within /usr/lib/portage, and only in /usr/lib/eclass/{kmod,kernel-mod}.eclass. If KERNEL_DIR is not intended for the "base" portage application I could also see overwriting KV in kmod.eclass but this seems an uglier solution.
Created attachment 42126 [details, diff] Patch to /usr/lib/portage/pym/portage.py This patch fixes the install problem for me. It changes the doebuild function to respect the KERNEL_BUILD setting when computing KV.
I noticed similar behavior using the new 2.6 ability to append a string on the end of your kernel name. The EBuild would place the modules in the 'old name' directory when in fact the rest of my modules were in the appended name. So all my modules would be in /lib/modules/gentoo-2.6.9-r1-pwned and the ebuild would place the nvidia module in /lib/modules/gentoo-2.6.9-r1. This computer is at work, but I'll try the patched version and see if it corrects my problem as well. Otherwise I'll probably submit a new bug ;0
No need for a new bug. There's already bug #67804, which has been released in portage-2.0.51-r5. The fix might also soon be superceded by the new kernel-mod.eclass.
We're moving away from portage setting KV, to using our own eclasses (linux-info and linux-mod) for this. We're also switching to KV_FULL to avoid conflicts. Will have to check if linux-info respects KERNEL_DIR in this respect.
Yep it does. Please bear with us while we convert all ebuilds to using linux-info, not a minor operation!
