Summary: | external kernel modules installed in wrong directory: KV vs KERNEL_DIR | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Neil Katin <neil+gentoo> |
Component: | New packages | Assignee: | Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | dev-portage, kernel |
Priority: | High | ||
Version: | 2004.2 | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Patch to /usr/lib/portage/pym/portage.py |
Description
Neil Katin
2004-10-18 14:43:45 UTC
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! |