(Bringing the sponsor of the last few uploads into Cc) I think there are up to three RC bugs here:
* on x86_64, libzebra.so is a broken symlink * on other architectures, every .so is a broken symlink * libraries with different versioning are sharing a package (Policy ยง8.1) The correct solution to those bugs depends on whether those libraries are intended to be used by code outside the quagga source package. There is discussion of whether these are public or private libraries on <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705306>, and I would recommend reading that bug before deciding. If these libraries are not useful to external consumers in practice, then it looks as though the quagga maintainer could treat them as private libraries. To do that, configure with --libdir=/usr/lib/quagga or similar, remove the libquagga0 and libquagga-dev packages, and ship /usr/lib/quagga in quagga-core or a new quagga-libs package instead. It looks as though every package that depends on these libraries depends on quagga-core anyway, so folding them into that might be simplest, and would avoid the NEW queue. gvfs-libs is a similar set of private libraries which could be used as a reference. You'll notice that libgvfscommon.so and libgvfsdaemon.so are (deliberately!) not installed in the default linker path, but instead are installed in a subdirectory; and there are no development files for these private libraries. However, if the quagga family of libraries are intended to be stable public API that can be used by code outside src:quagga, then Debian Policy chapter 8 is very relevant, and the bugs below should be fixed. If so, read on... First bug: broken symlink on x86_64 ----------------------------------- On Thu, 09 Mar 2017 at 00:06:32 +0100, Andreas Henriksson wrote: > On Mon, Mar 06, 2017 at 01:51:58PM +0100, Andreas Beckmann wrote: > > during a test with piuparts I noticed libquagga-dev contains a > > a broken symlink: /usr/lib/x86_64-linux-gnu/libzebra.so -> libzebra.so.0 > [...] > > So, libzebra.so.* is now libzebra.so.1 instead of .0 > > I see two options here... > > a/ drop the libzebra* (compatibility?) symlinks that's been carried since > forever since hopefully they are no longer needed. The ABI (and API?) > has even been broken since libzebra.so days. A symbolic link libfoo.so -> libfoo.so.0 in the -dev package is not some backwards compatibility thing, it's how the (compile-time) linker finds the library. `cc ... -lzebra` searches the default linter path for a file named exactly "libzebra.so" (no suffix). I think what is wrong here is that the package is creating these symbolic links "by hand" in the .links file, overwriting the ones that should have already been created by its Autotools build system. https://sources.debian.net/src/quagga/1.1.1-1/lib/Makefile.am/ looks like correct Autotools code to generate a library with SONAME libzebra.so.1; if I'm reading correctly, it should result in ${libdir}/libzebra.so.1.0.0 ${libdir}/libzebra.so.1 -> libzebra.so.1.0.0 ${libdir}/libzebra.so -> libzebra.so.1.0.0 without any further action by the Debian packaging. > b/ hope that despite the ABI (and API?) break, most old code still compiles > against libquagga.so.1 and bump the compat symlink so > libzebra.so points to libzebra.so.1 I don't see how redirecting the symlink to point to the right library could possibly be worse for external code than having a dangling symlink, which is clearly not going to work :-) The fact that this was only recently noticed suggests that nothing in Debian, outside src:quagga, actually links to this library (because if they did, it wouldn't work), which might support the point of view that these libraries could be treated as private libraries instead. Conversely, if they are intended to be public libraries, I would recommend having an autopkgtest similar to https://sources.debian.net/src/flatpak/0.8.3-1/debian/tests/build/ for every public shared library. If there is no suitable do-nothing function then you don't even need to call a function, you could do something like void *foo = (void *) some_function_in_the_library; printf ("%p\n", foo); (as long as there's some reference to stop -Wl,--as-needed causing false successes, on distributions whose gcc does that by default). Second bug: broken symlink on all other architectures ----------------------------------------------------- > While looking at this I also noticed another (somewhat related) issue. > The links file seems to hard-code amd64 multi-arch triplet in > http://sources.debian.net/src/quagga/1.1.1-1/debian/libquagga-dev.links/ > which is likely very wrong on any other architecture. > > Two possible soutions for that would be: > > x/ add dh-exec as build-dependency, chmod +x libquagga-dev.links > and use dh-exec shebang and a multi-arch-triplet variable expanded > by dh-exec at build time. > See https://manpages.debian.org/stretch/dh-exec/dh-exec-subst.1.en.html > > y/ create the symlinks directly from debian/rules instead of using a > debian/*.links file, where the multi-arch triplet should also be > available via some variable. I think the solution that is both simplest and most correct is: z/ stop re-creating the symlinks from debian/ and check that libtool gets it right without further intervention (from a quick look at the Makefile.am I suspect it will). Third bug: libraries with different SONAME versioning packaged together ----------------------------------------------------------------------- Lintian has done its best to advise the maintainer not to do this, but unfortunately the warning has been overridden. If these are public libraries, I would recommend not overriding "package-name-doesnt-match-sonames", and instead doing as Lintian suggests. This will require a trip through the NEW queue, unfortunately. S
