Bugzilla Bug 145962

Spent way too long tonight trying to make sense of the /etc/modules.conf, 
/etc/modules.d/ and /etc/modprobe.conf, /etc/modprobe.d/ interaction with
modules-update and generate-modprobe.conf.

Here's what I found:

For the 2.6 kernel (who give a *** about 2.4 anymore), we need have _either_
a /etc/modprobe.conf file, OR a /etc/modprobe.d/ directory tree.  If we have
the .conf file, the .d directory is never scanned.

Problem is, if you add a file to the modprobe.d/ directory with a "blacklist"
line in it, the combination of modules-update and generate-modprobe.conf
eats those lines for lunch, never to be seen again.

Either we need to add the ability for those scripts to handle the "blacklist"
items properly, or just drop the ability for the .d/ directory to be made
into a single config file, as that's not needed at all.

Oh, and don't get me started with the old module configuration files, I
eventually gave up and just deleted them from my system, which helped me
figure this all out...

So, any thoughts?

And do we really need all those aliases anymore?

the problem is legacy ... packages still install into /etc/modules.d and not
/etc/modprobe.d so there is no way for the new modprobe to know about these
config files unless we combine them via modules-update

the problem here i think is that we have generate-modprobe.conf filter
everything when in reality it should only be filtering the files for modules.d

so the fix is probably to accumulate the old cruft, filter it through
generate-modprobe.conf, and then append the new stuff

sort of like:
cat /etc/modules.d/* > old-cruft
TESTING_MODPROBE_CONF=temp generate-modprobe.conf > old-cruft.filtered
cat /etc/modprobe.d/* old-cruft.filtered > /etc/modprobe.conf

Two suggestions, independent of each other:

1. let files in modprobe.d override those in modules.d with the same name, so
an ebuild that cares can install both and in each situation exactly one (the
right one) will be used. I believe this will make life much easier in the
future.

2. use modprobe.d directly instead of generating modprobe.conf to reduce the
need for using modules-update for each and every change. However first it
should be verified that module-init-tools skip files like *~ and pals. This is
just an idea, not a strong wish, as I don't particularly care one way or the
other.

In terms of commands, building from the example in comment 1:
rm -f temp
for cfg in /etc/modules.d/*; do
  if [[ ${cfg} == *~ || ${cfg} == *.bak || ${cfg} == *,v ]]; then continue; fi
  if [[ -e "/etc/modprobe.d/${cfg##*/}" ]]; then continue; fi
  cat "${cfg}" >> temp
done
TESTING_MODPROBE_CONF=temp generate-modprobe.conf \
                         > /etc/modprobe.d/modutils-legacy
rm -i /etc/modprobe.conf

(1) already happens

i already explained why (2) cannot be [typically] done

also, *~ files and such are already ignored as well

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

(In reply to comment #3)
> (1) already happens
> 
> i already explained why (2) cannot be [typically] done
> 
> also, *~ files and such are already ignored as well
> 

2 works if the corresponding conf file is missing, I've been trying to do this
but an /etc/modules.conf file keeps coming back, not sure when.  Where are the
relevant docs?  I just found out that I needed to edit /etc/hotplug/blacklist
using Google, but how was I supposed to know this?

(In reply to comment #5)
> Where are the
> relevant docs?  I just found out that I needed to edit /etc/hotplug/blacklist
> using Google, but how was I supposed to know this?

/etc/hotplug/blacklist won't help anymore now...

fixed with module-init-tools-3.2.2-r2