When remerging nvidia-kernel (at least 1.0.4349 and 1.0.4349-r1) on kernel 2.5.66 portage unmerges the nvidia module for my 2.4.20 kernel and vice versa. I looked in the ebuild where the slot is explicitly set to the kernel version and compared it to /var/db/pkg/media-video/nvidia-kernel-1.0.4349-r1/SLOT - match. But still portage every time unmerges other modules. Reproducible: Always Steps to Reproduce: 1. Start a kernel. emerge nvidia-kernel 2. Start a different kernel. emerge nvidia-kernel 3. The older module gets unmerged.
Erm, this is a portage issue ????
Why wouldn't it be a portage issue? As I understand it, a package that's installed a second time but to a different slot should not unmerge the previous instance (which is installed to a different slot). Correct me if I'm wrong, but that's why I reported this as a portage issue. And: the slot in the nvidia-kernel ebuild _is_ set correctly to the currently running kernel version.
Are there any workarounds for this? It's making kernel testing difficult for me. Right now I'm trying to test interactivity in 2.6.0-test1 and 2.6.0-test1-mm2, and each time I switch between them, I have to re-emerge, and the other's nvidia drivers are deleted. Interestingly enough, it leaves my 2.4.20-gentoo drivers alone. I could probably just copy the files between the two /lib/modules/* trees, but then I would have an even more tainted kernel.
sure, just touch any file you dont want unmerged
I copy that - it's annoying especially now that we are all experimenting with kernels of 2.4 and 2.6-series
nvidia-kernel provides a kernel module, and as such should be slotted to the kernel sources it was built against. Could someone please add SLOT="${KV}" to nvidia-kernel to allow multiple versions for each installed kernel.
Sorry, am working with a user in #gentoo-bugs affected with this. Looking at the ebuild again it is already properly slotted, but Portage seems to ignore this.
I have another solution for this issue, until portage can handle the SLOT usage for this package correctly, but it's an ugly hack. If the ebuild touches the module in the pkg_postinst, the module mtime won't match the recorded one, and portage won't unmerge the module. I've tested and it works here. Could this be added to the ebuild, possibly with a local USE flag to allow the user to control it, until SLOT becomes a working solution?
We already implemented another hack to "solve" this problem, /lib/modules is now partly config-protected (it's unmerge-protected, but files can still be overwritten).
supposed to be fixed in 2.0.50 which is stable now. If this bug is not fixed please reopen.
This bug is not fixed, and may cause a system to become unuseable if the new kernel does not work (ie when upgrading a minor kernel version, but accidentally using a bad filesystem, etc)
Care to explain? Portage won't delete anything from /lib/modules so I don't see how your system could become unusable.
