Bug#680742: Bug#755846: Bug#756066: [libopenal1] Unable to install amd64 next to i386 library

[Patrick Matthäi]

Am 28.07.2014 um 21:25 schrieb Simon McVittie:
> severity 755846 normal
> block 680742 by 755846
> thanks
> 
> On Mon, 28 Jul 2014 at 10:20:47 +0100, Simon McVittie wrote:
>> On Sat, 26 Jul 2014 at 10:48:39 +0100, Simon McVittie wrote:
>>> My suggestion on [#755846] was to switch the "sndio" (really roaraudio)
>>> backend back to the way it had worked in 1.14 (it used dlopen), or to
>>> drop "sndio" support until roaraudio and its dependencies are multiarch.
>>> After doing either of those, the severity of #755846 can be dropped.
> 
> The maintainer of libopenal1 has disabled the "sndio" backend, and
> I've just done the necessary sponsored upload. This reopens #680742 (request
> to re-enable roaraudio support in libopenal1) and I think it makes
> #755846 (roaraudio libraries are not multiarch) non-RC.
> 
> I would recommend that roaraudio support in libopenal1 should not
> be enabled until this can be done without breaking multiarch.
> The test-case is that "apt-get install libopenal1:amd64 libopenal1:i386"
> should succeed on a mixed amd64 + i386 system.
> 
> Some possible things that could be done by people who like RoarAudio
> and would like it to be better-supported in Debian include:
> 
> 1. Add a real roaraudio backend in upstream openal-soft, and make sure it
> only needs a weak dependency on the roaraudio libraries. It's OK if systems
> without those libraries cannot use roaraudio, as long as the other backends
> can still work. For instance, the PulseAudio backend has a weak
> dependency on libpulse0; without that library, OpenAL cannot output
> to PulseAudio, but it can still output to, e.g., ALSA. That seems
> a good model to follow. If this is done, #680742 does not need to be
> blocked by #755846 any more.
> 
> 2. If sndio is intended to be (effectively) the "official" API for roaraudio,
> instead of approach 1 change the sndio backend in upstream openal-soft
> to be able to cope with a weak dependency on the roaraudio libraries (as
> it could in openal-soft 1.14), analogous to the above. If this is done,
> #680742 does not need to be blocked by #755846 any more.
> 
> 3. Make the roaraudio libraries multiarch co-installable (#755846).
> The test case that should work is that on an amd64 + i386 system,
> "apt-get install libroar2:amd64 libroar2:i386" should succeed,
> and if (any part of) libroar-compat2 is considered to be an important API,
> in addition "apt-get install libroar-compat2:amd64 libroar-compat2:i386"
> (or the equivalent for any new packages that are split out and considered
> important) should also succeed. This is A Good Thing in general, regardless
> of whether it blocks #680742.
> 
> 4. Get roaraudio support into some pluggable audio layer that OpenAL
> can use, instead of or as well as OpenAL itself, which would make #680742
> unnecessary. libasound2 and libportaudio2 look like plausible choices;
> libasound2 can already output through PulseAudio, which seems to be
> analogous to roaraudio, via libasound2-plugins. If you go this route, the
> Debian maintainers of those libraries are likely to insist that any new
> dependencies are multiarch-ready (and if they don't, they should)
> so approach 3 still applies.
> 
> The Debian maintainer of openal-soft has indicated that he is not
> interested in maintaining Debian-specific patches to hook roaraudio
> into openal-soft, so if you are going for approaches 1 or 2, please take it
> upstream. If you choose approach 4 it would be a good idea to go
> upstream too.
> 
> Regards,
>     S
> 


Hola,

sorry for this long delay.. Today I have just uploaded roaraudio
1.0~beta11-2 which also fixes #755934 (dropping decnet support) and I
have added multi arch control flags, ok there is a problem with the
compat package and the -dbg package, but that is not so important and I
will split them later to resolve these issues.

Is anything else missing from my side to solve this whole situation?


-- 
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatthaei at debian.org
        patrick at linux-dev.org
*/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-games-devel/attachments/20150727/3bd11b62/attachment.sig>