Bug#755846: libroar2: no multiarch possible

[bret curtis]

Hey there... an openal-soft maintainer here (who also works closely
with openal-soft upstream),

On Fri, Jul 25, 2014 at 3:20 PM, Philipp Schafft <lion at lion.leolix.org> wrote:
> reflum,
>
> On Fri, 2014-07-25 at 09:47 +0100, Simon McVittie wrote:
>> affects 755846 libopenal1
>> thanks
>>
>> > 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.
>

If someone wants to pick it up, dust it off, fix it up and upload it,
I doubt anyone would stop them. The problem now is finding someone
willing to do 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.
>

If no one is interested in fixing the problem, then yeah, the problem
gets dropped for the sake of expediency in solving a larger problem.

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

Roger that, I'll get on this. I plan on keeping with upstream so it is
likely that we'll go with option 2 until someone takes up the
roaraudio packages. At this point, unless someone takes up that torch,
we'll drop roaraudio-via-fake-sndio support until this gets fixed.
(See below as to the real problem.)

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

If someone would be so kind as to provide a patch upstream for Chris,
I'm sure he would take it. It would eliminate our
roaraudio-via-fake-sndio problem.

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

Is there already a bug filed for librms? If this is the root of all
evil and drama, then it should be handled.

Cheers,
Bret