Upgrades should probably change /etc/modules.conf (or /etc/conf.modules)
so that old module names are rewritten as the new names.
At least 3c90x (3c59x) has changed; I don't know if there is a list
Re-assigning to component "kernel".
This defect is considered MUST-FIX for Florence Release-Candidate #1
There was talk of doing this in the kernel package's %post, but that doesn't
seem right. You can install a 2.4 kernel and still want to fall back to a 2.2
kernel, so perhaps it should be a boot-time thing.
There are some nifty modutils directives for saying things like 'try 3c59x, and
if that doesn't work, try 3c90x'. I wonder if we should make use of them? Like
probe eth0 3c59x 3c90x
How about if the kernel spec requires sed and this gets put in %post:
[ -f $cnf ] || cnf=/etc/conf.modules
sed -e 's/^alias eth0 3c90x$/probe eth0 3c59x 3c90x/' $cnf > $cnf.tmp
mv -f $cnf.tmp $cnf
We already require a recent enough modutils I think.
I'd say this is a job for the hardware detection program.
It should find the card and see the correct module isn't assigned to it.
Bill, do you agree? It makes sense to me..
No. We explicitly do not change mappings for users on the premise
that if the user picked a particular driver, they did it for
Note that we're not necessarily talking about outright _changing_ the alias, but
rather adding a name, like:
before: alias eth0 3c90x
after : probe eth0 3c90x 3c59x
Eww. That would mean as soon as the installer writes a modules.conf,
kudzu would change it? There's something rather ugly about that.
It also means that you have to parse this other format to determine
what devices are configured.
Moreover, the kernel package already did this for the 2.2 kernel,
I don't see why it can't do it for 2.4.
In any case, we're now shipping the 3c90x driver in the kernel.
We should bring forward the 2.2 stuff to the 2.4 kernel, but it is
not critical unless the aacraid driver actually makes it in, since
that's currently the only use of it...
*** This bug has been marked as a duplicate of 25550 ***