affects 755846 libopenal1
thanks
On Thu, 24 Jul 2014 at 19:26:27 +0200, Patrick Matthäi wrote:
> Am 24.07.2014 um 12:14 schrieb Philipp Schafft:
> > upstream speaking,
I think this is a bug in the way OpenAL and/or roaraudio is packaged in
Debian, not in upstream code, so there isn't a great deal of relevance
for upstream here.
> I will have a look in the next days if it is possible with the current
> upstream code base.
I think the most appropriate answer would be for libopenal1 to either drop
the libroar-compat2 dependency again, or turn it into a dynamically-loaded
plugin that can be dropped to Suggests (like its dependency
on libportaudio2). I would say "... or Recommends, like libpulse0",
but according to popcon, roaraudio is several orders of magnitude
less widely used than pulseaudio, and only 0.45% of libroar-compat2
installations actually have roaraudio installed.
Looking into libopenal1 in more detail, it doesn't actually have a
backend to support roaraudio: what it supports is (among other things)
libsndio, which as far as I can tell is the OpenBSD audio API.
In OpenAL 1.14 this *was* dlopened, but in 1.15 it was changed
upstream to use ordinary library linking. That makes perfect sense
if you're on OpenBSD and libsndio is "the" audio API, but doesn't really
make sense on Debian where "sndio" is really roaraudio.
OpenAL maintainers, please consider reverting the sndio backend to use
dlopen like 1.14 did, or dropping roaraudio-via-fake-sndio support
until/unless someone provides an actual roaraudio backend analogous
to the pulseaudio backend. A real roaraudio backend would make configuration
make more sense, too: it seems more reasonable to enable roaraudio via
"drivers=roaraudio" than to use "drivers=sndio" and rely on knowing that
sndio is really roaraudio.
I notice this isn't the first time libopenal1 has had an undesirable
dependency chain from libroar-compat2: #673178.
Looking at the multiarch situation anyway, for completeness:
The libraries in libroar-compat2, which are all that OpenAL actually
needs right now, look superficially OK for marking as multiarch. However,
libroar-compat2 also contains /usr/bin/roarify which differs between
architectures (it contains absolute paths to libroar.so.2, libroaross.so.2,
/usr/lib/x86_64-linux-gnu/roaraudio/complibs, etc.).
If libroar-compat2 is meant to be for manual use, more like aoss, pulsedsp,
socksify etc., then nothing should be normal-library-linked to it.
I notice that OpenAL seems to be the only thing using its libsndio,
and the fact that it provides libsndio at all seems like an abuse of
the fact that (a) OpenAL happens to have a libsndio backend, and (b)
Debian happens to not have the real libsndio.
On the other hand, if the intention is that other packages should be
able to depend on the fake libsndio like libopenal1 does, I would suggest
either:
- generating a real libsndio2 package and having libopenal1 use that; or
- making roarify a separate package that is Architecture:any, not multiarch,
and depends on libroar-compat2 of the same architecture.
Further down the stack, libroar-compat2 depends on libroar2. libroar2 also
looks OK for multiarch: it only contains architecture-prefixed libraries.
However, libroar2 depends on libdnet (#755934, etc.) which is not ready for
multiarch: it contains /usr/lib/librms.so.2 which you will notice is not
architecture-prefixed; so making libroar-compat2 and libroar2 multiarch
while libdnet is used would just move this bug a couple of steps down the
stack, to "I can't install both libdnet:i386 and libdnet:amd64".
The rest of the libraries that libroar2 depends on are already multiarch.
S
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
