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

[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