[EMAIL PROTECTED] writes: >> Thomas Hood <[EMAIL PROTECTED]> writes: >> > If a fresh sarge/2.6 system lacks alsa-base then this would seem to be a >> > problem because in that case nothing enforces the mutual exclusion of OSS >> > and ALSA modules. If linux26 doesn't install alsa-base then perhaps it >> > should do so. Even better, possibly, would be to give the user a choice >> > between OSS and ALSA: if the user chooses ALSA then she gets alsa-base; >> > if she chooses OSS then she gets the (currently nonexistent) "oss" package >> > which blacklists ALSA modules. >> >> The kernel could blacklist alsa modules by default and the alsa-base >> would divert that to blacklist oss. That sounds the simplest. > > > So to be clear the alternatives suggested so far are: > > 1. The two-package approach > > * oss blacklists ALSA modules > * alsa-base blacklists OSS modules > * alsa-base Conflicts with oss > * kernel-image Depends on alsa-base | oss
I would prefer "oss | alsa-base". Oss always worked out of the box for me and alsa never. > 2. The diversion approach > > * ALSA modules are blacklisted by default > * alsa-base de-blacklists ALSA modules and blacklists OSS modules > * linux26 installs alsa-base > > Have I got that right? > -- > Thomas Hood Why should linux26 install alsa-base? That would mean OSS will always be blacklisted. It would be beter if the D-I arch-detect looks at the soundcard of the system and then recommends either OSS or ALSA as default depending on it. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]