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

[Patrick Matthäi]

Am 28.07.2015 um 13:48 schrieb Simon McVittie:
> Thanks for doing this. Unfortunately, I don't think this is sufficient
> to close #755846 yet, because of the compat package.

I hope -3 (NEW) will solve this situation at all from the src:roaraudio 
side.

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

np but thanks for your effort!

> 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

Thanks for pointing it out. With -3 libroar-compat2 is multiarch: same 
and the roarify tool is split out into a separate package.

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

I hope I have done it in the correct way.

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

Yes seems like a bug, fixed with -3: it provides now libsndio2

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

Also done.

-- 
/*
Mit freundlichem Gruß / With kind regards,
  Patrick Matthäi
  GNU/Linux Debian Developer

E-Mail: pmatthaei at debian.org
         patrick at linux-dev.org
*/