Fernando Pablo Lopez-Lezcano <[EMAIL PROTECTED]> writes: > > > Options: > > > a) define 'distribution="redhat"' for the mandrake detection > > > code _if_ the oss options erasure for redhat works fine under > > > mandrake (mandrake users should test this). > > > b) add another handler for mandrake's modules.conf oss options > > > (should be written taking into account whatever mandrake uses to > > > configure sound so that the proper strings are removed from > > > modules.conf). > > > > so why not doing such as threat all distros that provide > > /etc/redhat-release the same way. i don't think there's any > > distro out that provide /etc/redhat-release for compatibility that > > would like to have users loose their module configuration: > > With the patch I supplied no distros that user /etc/redhat-release > will lose their configuration (I hope, at least not due to the bug I > introduced a long time ago which is fixed by the patch). Distros > that are not RedHat or Fedora will execute the SuSE code path. > > Your patch is fine, I would say. But it has an assumption I don't > quite like. I wrote "remove_sndconfig_block" (basing it on > "remove_y2_block") by looking at all the strings that the sndconfig > utility was adding to modules.conf (sndconfig was the way RedHat was > doing sound configuration quite a while ago, I think this has > changed).
as for mandrake, we do not rely on sndconfig (though we still provide it for isa pnp sound card owners) drakx (the installer) and draksound (the standalone soundconfig tool) only write "sound-slot-X" aliases and "above XXX snd-pcm-oss" lines for oss compatibility (if $module =~ /^snd-/) in /etc/modules.conf > I assume the same happened when "remove_y2_block" was written (in > this case with SuSE's yast2). I don't know what sound configurators > are being used by other releases that use /etc/redhat-release > (mandrake is one, probably others?), mandrake does not use the sound alias nor any isa oss paremeters by default but sndconfig users will manually do. i guess someone that succesfully used sndconfig won't try alsaconf, but we'd better be idiot-proof and not remove such modules > they may be creating other strings in modules.conf that will not be > removed by "remove_sndconfig_block" so they may need custom > "remove_xx_block" functions that deal with what they add to > modules.conf. ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
