Here's a list of files present in module-init-tools which are missing in kmod: /etc/modprobe.d/dist-alsa.conf /etc/modprobe.d/dist-oss.conf /etc/modprobe.d/dist.conf I'm not sure if the last one is really necessary nowadays, but the first two are.
/etc/modprobe.d/dist-oss.conf is essentially an empty file. It contains nothing but comments. dist.conf and dist-alsa.conf were both explicitly removed from m-i-t under bug 725841. dist-alsa.conf only has a single line in it, and I'm not entirely sure it is even required. I don't see how these files are crucial at the moment. Is something not working correctly for you?
(In reply to comment #1) dist-oss.conf is essentially empty? Really? install snd-pcm /sbin/modprobe --ignore-install snd-pcm && /sbin/modprobe snd-pcm-oss && /sbin/modprobe snd-seq-device && /sbin/modprobe snd-seq-oss Oh, yes, OSS applications magically stopped working in F17, you know /dev/dsp* and /dev/mixer* files are missing. dist-alsa.oss installs sequencer support, so you're right, maybe no one in this universe wants it: install snd-pcm /sbin/modprobe --ignore-install snd-pcm && /sbin/modprobe snd-seq You were right all the way through. Who needs OSS and sequencer support nowadays? All Fedora applications use ALSA/Pulse, so old and proprietary applications can just go the way of dodo. Thank you very much. I, for one, can pull these files from RPMs. With an attitude like this I don't think this bugs needs any positive resolution.
(In reply to comment #2) > (In reply to comment #1) > > dist-oss.conf is essentially empty? Really? > > install snd-pcm /sbin/modprobe --ignore-install snd-pcm && /sbin/modprobe > snd-pcm-oss && /sbin/modprobe snd-seq-device && /sbin/modprobe snd-seq-oss Yes, that line exists however it is installed as commented out. It does nothing unless someone manually edits it. Do you have a package in Fedora that requires it? > dist-alsa.oss installs sequencer support, so you're right, maybe no one in this > universe wants it: > > install snd-pcm /sbin/modprobe --ignore-install snd-pcm && /sbin/modprobe > snd-seq snd_pcm is still loaded in f17. snd-seq is still built and can still be loaded. Do you have a package that requires it? > You were right all the way through. Who needs OSS and sequencer support > nowadays? All Fedora applications use ALSA/Pulse, so old and proprietary > applications can just go the way of dodo. Thank you very much. I can't comment on proprietary applications much. If they need OSS and sequencer support, perhaps whomever is packaging them can include the modprobe files. > I, for one, can pull these files from RPMs. With an attitude like this I don't > think this bugs needs any positive resolution. I really wasn't gving an "attitude". I asked if you were having a problem and you decided to become rather hostile. If there is something in Fedora broken by not shipping those files, we can possibly move them to another package. Kmod itself doesn't need to ship them.
I wasn't really hostile, more sarcastic, but there is a reason for that. Previously we (Fedora/classic RedHat Linux) had a feature which could be easily enabled (mind that other distros enable it by default, but let's forget about that for a second) by editing dist-oss.conf. Now what you are basically saying - "I don't know any OSS applications that I care for, so users should google how to enable this feature (and master the terminal, su, sudo, modprobe commands), ISP vendors (instead of pointing the user to those files) now _each_ must supply files for /etc/modprobe.d/* (probably causing file conflicts)". If you don't feel like adding back those files which used to *belong* to modprobe, I am interested in what other package can accept them. Possible candidates are: kernel and alsa-lib (very very debatable). Hm. That leaves us with the kernel and kmod. Sorry, with the kernel. OK, reassign this bug to the kernel and let's see what kernel guys will say and what their excuse not to bundle those files will be ('cause I'm quite sure they will say - they don't belong to us). As for applications which still use OSS, here's a very incomplete list: SDL based applications libao based applications different old games based XMMS Not to count dozens of old applications which are not bundled by Fedora.
(In reply to comment #4) > I wasn't really hostile, more sarcastic, but there is a reason for that. > > Previously we (Fedora/classic RedHat Linux) had a feature which could be easily > enabled (mind that other distros enable it by default, but let's forget about > that for a second) by editing dist-oss.conf. > > Now what you are basically saying - "I don't know any OSS applications that I > care for, so users should google how to enable this feature (and master the > terminal, su, sudo, modprobe commands), ISP vendors (instead of pointing the > user to those files) now _each_ must supply files for /etc/modprobe.d/* > (probably causing file conflicts)". No, that's not really what I was saying, but that's irrelevant. > If you don't feel like adding back those files which used to *belong* to > modprobe, I am interested in what other package can accept them. > > Possible candidates are: kernel and alsa-lib (very very debatable). Hm. That > leaves us with the kernel and kmod. Sorry, with the kernel. alsa-lib sounds perfectly viable to me. Both conf files are directly related to alsa. We recently added a modprobe conf file to nfs-utils for an NFSv4 related issue. Let's reassign this there, and I'll create a patch to install it in a proper location.
Created attachment 581639 [details] Install alsa related module conf files
Jaroslav, does the attached patch look good to you?
It looks good. I pushed your patch to alsa-lib rawhide package. Please, close this bug when the config files are removed from module-init-tools .
(In reply to comment #5) Thank you very much! I'm really sorry for being kinda coarse.
(In reply to comment #8) > It looks good. I pushed your patch to alsa-lib rawhide package. > > Please, close this bug when the config files are removed from module-init-tools Already done (via kmod). Thanks much!