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

[Simon McVittie]

On 27/07/15 21:56, Patrick Matthäi wrote:
> Am 28.07.2014 um 21:25 schrieb Simon McVittie:
>> I would recommend that roaraudio support in libopenal1 should not
>> be enabled until this can be done without breaking multiarch.
> 
> sorry for this long delay.. Today I have just uploaded roaraudio
> 1.0~beta11-2 which also fixes #755934 (dropping decnet support) and I
> have added multi arch control flags, ok there is a problem with the
> compat package and the -dbg package, but that is not so important and I
> will split them later to resolve these issues.

Thanks for doing this. Unfortunately, I don't think this is sufficient
to close #755846 yet, because of the compat package.

(Before I start on technical details, I should clarify that I am not the
OpenAL maintainer, so please do not interpret anything I say here as a
promise to enable Roaraudio in OpenAL after you make certain changes in
Roaraudio. Having the dependency chain be multiarch is a prerequisite
for enabling roaraudio (resolving feature request #680742), but it is up
to the OpenAL maintainer whether it will actually be enabled, or whether
#680742 is wontfix.)

The desired test-case is that if you make a locally patched build of
libopenal1 that re-enables Roaraudio, put it in an apt repository (e.g.
using reprepro), and enable that apt repository on an amd64 machine,
then this should work:

    dpkg --add-architecture i386
    apt-get update
    apt-get install libopenal1:amd64 libopenal1:i386

Until that works, #755846 isn't fixed, and #680742 should be considered
to be blocked.

In particular, if consumers of Roaraudio would normally depend on
libraries from libroar-compat2, which libopenal1 seems to do in
practice, then those also need to be made available in a multiarch way
before #755846 can be considered fixed. Otherwise, enabling roaraudio
support in packages like libopenal1 would still break their multiarch
co-installability.

I realise there's a problem there because of /usr/bin/roarify, which is
not (and cannot be) architecture-neutral; so you'd probably need to
split out a new binary package for the bits that can be multiarch
(libsndio.so.2 etc.) and change the shlibs machinery so that users of
those compat interfaces get a dependency on the new, multiarch-capable
package, instead of on libroar-compat2.

It would probably be good to distinguish between the compat libraries
that are intended to be loaded by library dependencies (analogous to the
way libgamin0 and libjpeg62-turbo are drop-in replacements for libfam0
and libjpeg62), and the compat libraries that are intended to be
LD_PRELOADed or placed in the LD_LIBRARY_PATH to override existing
libraries (analogous to the way libfakeroot and libpulsedsp override
libc functions). The most correct packaging for one is unlikely to be
the same as the most correct packaging for the other.

If there is never going to be a non-Roaraudio implementation of the
sndio API in Debian, then one possible way to resolve the situation for
that particular library (which AIUI is the one openal-soft can use?)
would be a new multiarch:same binary package "libsndio2" containing
libsndio.so.2. I notice that libroar2-compat currently Provides
libsndio1, but actually contains libsndio.so.2 - that seems like a bug?

Unlike the compat package, multiarchifying the -dbg package(s) is not
required for #755846, although it would be nice (and might just be a
matter of dropping its non-multiarch dependencies down to Recommends,
since roaraudio-dbg ships build-id-based debug symbols which won't
collide across architectures).

    S