Bug#755846: libroar2: no multiarch possible

[Simon McVittie]

On 25/07/14 14:20, Philipp Schafft wrote:
> I just answerd because this report hit our mailinglist's spam filter
> somehow.

As I said, this is entirely about how roaraudio's packaging in Debian
(and that of its dependencies, and that of things that depend on it) is
set up - the optional features that are enabled, the library
installation paths, and how the binary packages are divided up. The only
upstream code that's relevant to this particular issue is in OpenAL,
where the sndio backend changed from using dlopen to using direct
linking, which moved libroar-compat2 from a weak dependency (Suggests)
to a mandatory dependency (Depends). That's why I suggested that it's
the Debian maintainers of libopenal1 who should deal with this in the
first instance.

OpenAL can also output to PulseAudio, but libpulse0 is, appropriately, a
weak dependency (Recommends); if you want to have libopenal1 installed,
but libpulse0 or one of its dependencies is problematic, then that is
entirely possible to do.

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

That would be part of the ideal solution.

However, I'm not going to work on that myself, because I have never used
roaraudio, or had any reason to use it. My only interactions with
roaraudio have been when it breaks the ability to install something that
I do care about. If someone *does* care about roaraudio in Debian, it's
up to them to make it not break other things.

"There is no cabal" - there is no central dictator saying "roaraudio
must be removed from Debian now" or "Debian wants to use
(pulseaudio|roaraudio|ALSA|OSS|printf '\a') as its preferred audio
subsystem" or anything like that. There are only cooperating maintainers
making the best distribution we can, and sometimes that means a
judgement call on sacrificing less-used functionality that is breaking
things elsewhere.

> Why is there no one working on getting librms fixed?

Yes, ideally libdnet would be set up to be multiarch too. Again, I have
no interest in being able to network to obsolete Digital machines, so I
don't plan to contribute to libdnet; anyone who does care about DECnet
is welcome to do so. My only interaction with libdnet is "this thing I
have never wanted to use is a mandatory dependency, and is causing
tangible problems for things I do use".

> At least upstream
> wasn't informed about any problem so it's debian internal again?

Yes, this Debian bug report in the Debian bug tracking system is
internal to Debian, and AIUI nobody has asked you to do anything about
it. If roaraudio's Debian bugmail goes to you and you don't want it to,
I suggest changing that.

> Users normally don't
> want features to be droped when they can be fixed.

No, they don't; but please look at this from the point of view of
someone who has no interest whatsoever in roaraudio. I tried to upgrade
libopenal1. Because I occasionally use Wine for Windows binaries, I need
both libopenal1:amd64 and libopenal1:i386 installed. At the moment, I
can't have the current version of libopenal1 (and new installations
would be impossible), for the benefit of an optional feature that makes
libopenal1 able to output through a sound daemon that I don't even have.

wine's popcon report says it has about a thousand times as many
installations as roaraudio, and right now, it's uninstallable in
unstable because of this bug. Ideally, libopenal1 would hook up to
roaraudio in a way that does not introduce a hard dependency. But the
world is not perfect, and until or unless that happens, it's a matter of
"least harm" - I would rather break (libopenal1 output to) roaraudio for
some people, if the alternative is breaking wine for a thousand times
that many people.

    S