Bugzilla Bug 1477

When you build modules which are not part of the kernel, for example the alsa
or
the pcmcia_cs modules, emerge should remove the previous version of a module
ONLY for the currently running kernel hierarchy and not from a different kernel
version.  In the current system, the modules are removed even from a different
kernel version causing problems when trying to boot using the other kernel.

yep, we need to fix this.

This has been annoying me too and I have been manually copying

/lib/modules/<last-kernel-drivers were emerged against>

to a backup diirectory, performing the emerge and then restoring the directory.

I just had a thought, could CONFIG_PROTECT be used to protect /lib/modules/* ?

Thus prevent a re-emerge from deleting the previous emerge that was done against
a different kernel.

*** Bug 9561 has been marked as a duplicate of this bug. ***

*** Bug 12170 has been marked as a duplicate of this bug. ***

*** Bug 12690 has been marked as a duplicate of this bug. ***

*** Bug 22177 has been marked as a duplicate of this bug. ***

I've proposed a portage patch that could fix this issue on bug #24990.

*** Bug 29240 has been marked as a duplicate of this bug. ***

I'm not really clear what SLOT's have to do with this problem It seems to
be something that is unique to kernel modules. I sort of like the CONFIG_PROTECT
idea, though.

CONFIG_PROTECT seems to work for me.  I made a new kernel 2.4.23_pre6-gss-r1
and still had 2.4.22_pre2-gss.  The video directory was wiped from 2.4.22_pre2-gss

when I emerged nvidia-kernel.  I use:

env AUTOCLEAN="no" ACCEPT_KEYWORDS="~x86" emerge nvidia-kernel, so the 
env AUTOCLEAN="no" setting gets ignored.

...so I added CONFIG_PROTECT="/lib/modules" to /etc/make.conf and that seems
to do the trick.

BTW here's a useful script from Georgi that tells you which ebuilds are affected:

###############################################
#!/bin/sh
# /usr/local/bin/kernel-deps
# list the ebuilds that depend on kernel version.
# suggested by Georgi Georgiev <chutz@gg3.net>

for i in `grep -l ' /lib/modules/' /var/db/pkg/*/*/CONTENTS`; do
	ii=`dirname $i`;
	cat $ii/COUNTER; echo " $ii";
done | sort -n | cut -f5,6 -d/ | sed -e 's/^/>=/'
###############################################

*** Bug 32019 has been marked as a duplicate of this bug. ***

This needs to get fixed soon. This bug has been open for well over a year.

OK, I fixed this. /lib/modules is now "unmerge protected", which means that
nothing in /lib/modules will get unmerged (sorta like how config protection
works), but if you upgrade a module it won't get named ._cfg0000_nvidia.o
for example. This is actually a good approach since ebuilds like emu10k1
install a module *and* supporting tools. You wouldn't want to put each emu10k1
ebuild in a different SLOT since those supporting tools do overwrite each
other. This is a nice compromise that didn't require massive hacks, and should
fix all user problems.

This fix should show up in Portage 2.0.49-r17.

I was doing some testing for Bug 34921 (A proposed script to rebuild third
party packages that supply kernel modules)  For the testing I installed portage
2.0.49-r18.  During my testing, modules were still removed from /lib/modules. 
Full test results are located at the above mentioned bug.  Is there something
that needs to go into make.globals or make.conf that I somehow missed when
upgrading? Here is the output from emerge info.  I will supply make.* files if
needed to determine what is wrong.

Portage 2.0.49-r18 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r3,
2.4.22-gentoo-test-r1)
=================================================================
System uname: 2.4.22-gentoo-test-r1 i686 Intel(R) Pentium(R) 4 CPU 1.80GHz
Gentoo Base System version 1.4.3.10
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CFLAGS="-march=pentium4 -O2 -pipe"
CHOST="i686-pc-linux-gnu"
COMPILER="gcc3"
CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config
/usr/kde/3.1/share/config /usr/kde/3/share/config /usr/share/config /var/bind
/var/qmail/control"
CONFIG_PROTECT_MASK="/etc /etc/gconf /etc/env.d"
CXXFLAGS="-march=pentium4 -O2 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoaddcvs ccache fixpackages sandbox"
GENTOO_MIRRORS="http://gentoo.oregonstate.edu"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="X acpi alsa arts avi berkdb cdr crypt cups dvd encode esd fbcon foomaticdb
gdbm gif gpm gtk gtk2 imlib java jpeg kde libg++ libwww mad mbox mikmod mmx
motif mozilla moznocompose moznoirc moznomail mpeg ncurses nls oggvorbis opengl
oss pam pda pdflib perl png ppds python qt quicktime readline sasl sdl slang
spell sse ssl svga tcltk tcpd truetype usb x86 xml2 xmms xv zlib"

After searching and diff'ing through CVS, I have noticed that the fix isn't in
the source tarball that is downloaded and built.  The CVS header for the
current portage.py shows version 1.341 while, the CVS header for the fixed
version is 1.345  Do we have an idea which release the fixed portage.py will
actually make it into the source tarball? The information given in the previous
comments is misleading as it indicates that the fix is in 2.0.49-r18 when it
actually is not.

*** Bug 35587 has been marked as a duplicate of this bug. ***

*** Bug 37800 has been marked as a duplicate of this bug. ***

*** Bug 94953 has been marked as a duplicate of this bug. ***