Bug 7343

I'm filing this as a new bug report, even though I have figured it out
(see the summary and below) and solved it by now, and though it is quite
similar to bug 4819; the reason it that I believe it IS a bug (whereas 4819
is classified NOTABUG), and because it had got me puzzled for a long time.
I'll start with the description I had written before I had found it out:

After upgrading to kernel 2.2.12 (with corresponding new initscripts), I
found that sound was no longer functioning, and errors pertaining to sound
modules were signalled during bootup. So I renamed /etc/isapnp.conf and
/etc/conf.modules so as to begin with a clear slate, and ran sndconfig
(also form redhat 6.1, version sndconfig-0.38-1). It starts correctly
recognising the sound card, a Creative ViBRA16X PnP. Then it goes on to
play a sound sample, which fails, with the message:

  The following error occurred running the modprobe program

  /lib/modules/2.2.12-20/misc/sound.o: a module named sound already exists

  soundcore: Device or resource busy
  sound: No such file or directory

Exiting sndconfig at this point leaves the following file /etc/conf.modules
(I don't include /etc/isapnp.conf, as it is quite long):

  alias sound sb
  pre-install sound /sbin/insmod sound dmabuf=1
  alias midi opl3
  options opl3 io=0x388
  options sb io=0x220 irq=5 dma=1 mpu_io=0x330

Leaving this file as it is causes the same error found by sndconfig to be
reported at boot time, and sound does not function. The error message
issued by modprobe is understandable, since one can find in
/lib/modules/2.2.12-20/misc/ files names sb.o AND sound.o; therefore the
line `alias sound sb' seems to be doing something that is not in order.
Indeed, by changing "sound" in that line, and its first occurrence in the
next line, into something that does not correspond to an existing module
(the name I tried was "soundcard"), one succeeds in getting sound to
function; one must also make this substitution in /etc/rd.d/rc.sysinit.

The program /sbin/modprobe I used is from modutils-2.1.85-4, not from the
latest version modutils-2.1.121-14 shipped with redhat 6.1. To my surprise
(because it seemed the the problem was a badly chosen alias name, not the
functioning of modutils) the problem disappeared when I finally got around
to upgrading modutils. Note however that I had not broken any recorded
dependency by upgrading initscripts and sndconfig without changing
modutils. In fact the dependency in initscripts explictly states
"modutils >= 2.1.85-3", so it should have worked withmodutils-2.1.85-4;
sndconfig does not mention modutils at all (I think it should though, as it
is calling modprobe). I hadn't initially upgraded modutils, as it depends
on vixie-cron, whose rpm I had not fetched because nothing in its
description suggested that it was essential for properly functioning a
basic system.

So two questions remain, for which I would like to know the answer.

First, why dosndconfig/rc.sysinit choose an alias name that conflicts with
an existing kernel module, while (it seems to me) any other name would do
better? And was modprobe specially modified to allow such practice, just so
that there could be a gratuitous incompatibility with older versions?

Second, why do sndconfig and initscripts not declare their dependency on a
recent version of modutils, while they seem to deliberatly exploit a
recently added feature? In fact this is far from the only case where
upgrading on a package-by-package base, without _ever_ overriding
dependencies, broke some part of the system; almost every functionality
that I normally depend on has been broken at some point. I am tempted to
conclude that either (1) RPM technology is incapable of describing the kind
of dependencies that actually exist between packages in a redhat system, or
(2) RedHat doesn't really care about properly recording dependencies
because they want people to buy a boxed set (for every new release) and
than either do a completely new install, or at best an upgrade in one fell
swoop (cross your fingers, emergency power generator on stand-by) from CD.