Bugzilla Bug 214035

/etc/modules.d is long deprecated. Please provide an equivalent /etc/modprobe.d
file instead.

I've decided that, with 20080710 and on, the functionality provided with the
old modules.d file will be removed. In the future, the ebuild will check for
the existence of CONFIG_DRM in the kernel (set to M or Y) and bail if it's
there. This will cause it to refuse to install alongside kernel drm.

I have a few reasons for the decision, and hoepfully it won't affect many end
users very much.

First of all, the new modprobe.conf(or .d) file does not naturally provide the
mechanism to override installed modules in a separate path in the module
directory. This means that if the in-kernel drm is installed as modules, their
usual place in /lib/modules/KV/kernel/drivers... would be searched _before_
/lib/modules/KV/x11-drm. There's no facility provided by modprobe.conf to
change that.

Second, although there is a very hackish way to achieve that (using shell
commands in modprobe.conf/d), it's ugly and may not be foolproof. I had a test
version in the tree, masked, but it's not a very good solution at all in my
mind.

Finally, keeping two sets of DRM modules for one kernel can end up confusing
the end user and could lead to all sorts of problems with symbol mismatches or
the user expecting one thing to happen, while another does. As it is, I hate to
remove flexibility, but there's no better way that I can see to do this with
what we've got now.

That said, is there a preferred way to handle the snapshots already in the
tree? If not, I can go about removing modules.d and adjusting the linux-info
checks. It looks like we'll need to keep an older snapshot around for stable
xf86-video-i810 and possibly others.

All ebuilds have had the modules.d file removed and check for CONFIG_DRM=n.

I have one objection. When I uninstall x11-drm it removes all kernel modules
from all my /lib/modules/2.6.*/ subdirs, right? I don't like this solution. If
multiple version (/slots?) would be possible then it is fine. Imagine, I often
test several kernels and do not want to have only one drm driver installed for
a single kernel.

Actually those modules are kept due to the config protection system (usually
used under /etc, which is also applied to /lib/modules). That means that upon
unmerging the package, you'll see the following in the removal output...

--- cfgpro   obj /lib/modules/${KV}/x11-drm/drm.ko
--- cfgpro   dir /lib/modules/${KV}/x11-drm

This is necessary for properly handling multiple kernels, as you wish. We used
to SLOT kernel module ebuilds but it was an ugly solution that led to a whole
lot of slots for users with multiple kernels.

The one drawback of the current implementation is that if you remove x11-drm
for a specific kernel, then merge a new one for that same kernel, portage will
detect a collision between the old modules (which are still there) and the new
ones being merged.