Charles A Edwards <[EMAIL PROTECTED]> writes: > My point was that because I update using urpmi I had both libalsa1 > and 2 installed and prior to this thread there had been nothing to > indicate that libalsa1 is useless.
ok then here is the explanation. the alsa team design and release alsa-0.5 but then they saw that their api wasn't complete for some professional stuff. they redesign their api and thus came alsa-0.9. apps can either use directly the kernel alsa api or libalsa which is more high-level. the interface between kernel alsa drivers and libalsa had changed as did the libalsa api. thus, the lib major was updated (1 => 2). so both lib can theorically coexists pacefully ... if they both were able to dialog with alsa modules ... so we're switching from alsa-0.5 to alsa-0.9 as now the new alsa api has been frozen. i've first made the kernel team updates the alsa driver, then recompiles alsa libs, then began updating my packages and warn our packages maintainers that their packages have either: - to be rebuild without alsa support - to be rebuild with alsa-0.9.x support if possible (either patchable or both alsa api're supported) > > libalsa1 is dependant of kernel alsa-0.5.x whereas libalsa2 is > > dependant on kernel alsa-0.9.x. > > I am not arguing just giving the info as supplied by rpm. i added an explicit requires on kernel > 2.4.18 because of the alsa update. that's all :-) > > you can have libalsa withouth an alsa aware sound driver. > > but having libalsa1 when you know that no more driver is using > > 0.5.x api is useless > > Again prior to this thread there was nothing that provided this info > if both pkgs were installed leading, at least me, to the mistaken > belief that both still functioned. i hope the above explanation is enough. if not you know who to send bombs :-( -- "il a ete brule au 28e degre" (the naheulbeuk witch) "c curieux, gcc fonctionne" (gwenole)
