Bug#755846: libroar2: no multiarch possible

Fri Jul 25 13:20:37 UTC 2014

reflum,

On Fri, 2014-07-25 at 09:47 +0100, Simon McVittie wrote:
> 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 just answerd because this report hit our mailinglist's spam filter
somehow.

> > 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.

RoarAudio isn't used in Debian *because* Ron Lee droped all the useful
dependencies to it while his personal vendeta (see the archives).
Droping dependencies is what broke the package.
And Debian seems to be all about 'drop it, NEVER fix it!'. This bug
report supports this. It's no longer about fixing but went directly into
a droping request.

As upstream I often hear from people that they wonder why RoarAudio
isn't working when they install the debian package: The answer is
because Debian decided (see archives) NOT to support RoarAudio because
of.... in fact I never heared about any technical reason for that.

I will consider to recommend Patrick Matthäi to send a removal request
for RoarAudio as this ongoing drama is more harming the RoarAudio
project than bringing anyone forward.

Btw. as you also pointed to the DECnet support: It's perfectly the same:
Dependencies to it were drop not fixed so it became useless while I see
people worring about it on the project's mailinglist as they actually
use it to make money.

It's said to see such a grate project as Debian being no longer
interesting in fixing problems.

> 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.

If someone is going to work on this, please let me know. I'm sure this
can be done in a nice and smooth way!

> 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.

It's consider to be useful for the user. That includes *both* manual use
and direct linking. This is why directlinking works at all. Because it
is designed to do so.

> 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

As there is currently no other implementation I consider libroarsndio
the non-openbsd port of libsndio.

> - 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.

Please see roar-config --list-path. It will tell you how libroar sees
the filesystem. Note that every entry can be altered if needed.

> 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".

This is what I meant above: a sub-sub-sub-sub-sub depneds of a is not
ready (but could be fixed) so let's drop a direct depends. Yay.

Why is there no one working on getting librms fixed? At least upstream
wasn't informed about any problem so it's debian internal again?

> The rest of the libraries that libroar2 depends on are already multiarch.

Please don't consider this mail to be directed against you. Just
consider it a push into the direction of the users. Users normally don't
want features to be droped when they can be fixed.

I'm still open to help fixing stuff. But make it possible to help fixing
and not break stuff again.

Thank you for your work and have a nice weekend. :)

-- 
Philipp.
 (Rah of PH2)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-games-devel/attachments/20140725/f73638a4/attachment.sig>