| Summary: | ExtractKernelVersion does not take into account LOCALVERSION | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Owen Gunden <ogunden> |
| Component: | Core - Ebuild Support | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | patch to support CONFIG_LOCALVERSION in KV | ||
Created attachment 43754 [details, diff]
patch to support CONFIG_LOCALVERSION in KV
|
New 2.6 kernels have the option CONFIG_LOCALVERSION which can be set to an arbitrary string that is tacked on to the kernel version. The function ExtractKernelVersion which is defined in portage.py (2.0.51-r3) does not take this into account. This causes things like kernel modules to be installed in the wrong location. For example, I'm using a LOCALVERSION of "ogunden1" and so my kernel modules all go in /lib/modules/2.6.9-gentoo-r3ogunden1 . However, the nvidia-kernel simply installs modules into /lib/modules/${KV} (in this case, that's /lib/modules/2.6.9-gentoo-r3 which is WRONG). This could be fixed at the ebuild or eclass (kernel-mod.eclass) level, but after studying the issues and thinking hard, I'm pretty sure the right thing to do is to have KV include the LOCALVERSION. If you disagree I'd be glad to open a dialog about that. I'm attaching a patch for portage.py which I've tested on my LOCALVERSION'd kernel as well as a kernel without a LOCALVERSION--in both situations, the nvidia-kernel module installs correctly for me. Reproducible: Always Steps to Reproduce: 1. install a kernel with CONFIG_LOCALVERSION set no a nonempty value 2. emerge nvidia-kernel 3. watch it install to the wrong directory