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: [email protected] [email protected] */ -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
