|--==> Wouter Verhelst writes: WV> [1 <text/plain; us-ascii (quoted-printable)>] WV> On Wed, Oct 13, 2004 at 10:51:46AM +0200, Marco d'Itri wrote: >>On Oct 13, Thomas Hood <[EMAIL PROTECTED]> wrote: >>> Lots of users are reporting that ALSA sound doesn't "just" work when >>> they install it. The cause of the problem is the fact that discover >>> loads OSS modules even when ALSA modules are available. This bug cannot >>> be worked around consistently with policy because discover offers no >>> mechanism for blacklisting modules other than editing a conffile. The >>> bug report against discover1 (#220616) has been tagged "wontfix" so I am >>> not expecting the discover maintainers to solve the problem. >>Discover should not try to load drivers for PCI devices AT ALL, we have >>hotplug for this.
WV> The reverse could be (and has been, on multiple occasions) said about WV> hotplug. I thought hotplug was dealing with hot plugging devices (pcmcia, usb, etc.) WV> The issue is that there are multiple auto-detection schemes in the WV> archive, currently, all of which will check what hardware is available WV> in the system, what driver can support that hardware, and which will WV> load the appropriate driver. WV> In this thread discover, discover1, and hotplug have been named; but WV> there are more -- at least at one point, we have (had) kudzu packaged WV> for Debian as well. WV> Apart from that, there's also the 'canon' way of managing modules WV> (/etc/modules), and a number of other packages which will load modules WV> to be able to do what they're installed for (hardware driver support WV> packages such as the ALSA ones, but also stuff such as binfmt-support WV> and nbd-client). WV> This multitude of packages doing stuff with modules is bound to break WV> eachother. Perhaps it's time to create a scheme which will allow WV> packages to load modules without stepping on eachother's toes? I definitely agree, some rational is needed here. WV> Such a scheme would WV> * Require init scripts to ask the central module handling system WV> permission to load a module, with a description of what purpose the WV> module serves. WV> * Not do anything if the central handling system forbids it. WV> * Optionally keep track of what modules are loaded by what package, for WV> debugging purposes. WV> * Allow packages to register themselves as the 'preferred' handler of WV> the module at postinst time (similar to the alternatives system; this WV> would solve the current issue ALSA has). WV> * Give the local admin the ability to override such decisions, or to WV> disable the loading of certain modules. Seems a good scheme to me. For the record I've made a custom discover1-data package which uses ALSA in place of OSS: http://apt.agnula.org/demudi/pool/local/d/discover1-data/ Cheers, Free
