Dear portage maintainers, when using the binary packages features offered by Portage for kernel modules the actual modules can end up in the wrong location. This happens because the kernel's modules directory is dynamic and depends on the kernel's name, so the kernel modules as stored in the binary package use the module path of the kernel config that was active during the binary package build, whereas the module path on the host that's emergeing the binary package can (and probably will be at a certain point) be different. emerge @module-rebuild doesn't trigger a rebuild of the module if the path's don't match. P.S. This is my first bug report for Portage, so if I missed something or did something wrong please let me know so I can correct it where necessary. Reproducible: Always Steps to Reproduce: 1. Configure a local version in the kernel config 2. emerge a binary package for a kernel module (I'm using ZFS and nvidia) 3. Change the local version in the kernel config 4. emerge the same kernel module (or use emerge @module-rebuild) while using --usepkg(only) or --getbinpkg(only) together with PORTAGE_BINHOST. Use emerge -v to show the list of files that are installed. Actual Results: The existing binary package gets used and the modules get installed again to the old kernel's module directory. No modules get installed in the new kernel's module directory. Expected Results: Portage notices there's a difference in the kernel's name/module path and rebuilds the module. I think this is the safe/most widely usable choice. An alternative could be to try to install the modules from the binary package to the correct directory, but then there's no way to know if there are actual changes between kernel versions that are relevant for that kernel module which could cause the modules in the binary package to fail.
