Bug#856936: quagga: libquagga0 contains libraries with different SOVERSIONS

[Simon McVittie]

On Mon, 13 Mar 2017 at 23:43:52 +1100, Scott Leggett wrote:
> FYI the version bump originated from this post to the upstream mailing
> list[0], which shows upstream's somewhat relaxed attitude to ABI
> stability. I guess this is understandable as the libraries are intended
> to be private.

This looks like good evidence for moving the libraries into quagga-core
being the right way to resolve this bug.

S

Bug#856936: quagga: libquagga0 contains libraries with different SOVERSIONS

[Scott Leggett]

Hi all,

Thanks for the bug report and for the thoughful advice.

On 2017-03-10.11:18, Vincent Bernat wrote:
>  ❦ 10 mars 2017 09:29 GMT, Simon McVittie  :
> 
> >> I suppose that's why I am in copy (the other actions are pretty obvious
> >> and I suppose Scott will apply them soon; I can also do that if he's
> >> unavailable).

Yes, I will make the changes suggested by Simon. I won't be able to do
this in the next few days, but will get it done within the next week
after that.

As the libraries are really intended to be private to the quagga
"family" of daemons/utils, I plan to roll them into quagga-core (thanks
for the explanation for how to do this correctly!).

> >
> > The other reason I wanted to Cc you is because as sponsor, you were
> > responsible for checking that the package split proposed by the
> > maintainer was Policy-compliant. I would have expected a sponsor to
> > query the current library packaging and not upload without changes,
> > because as it stands at the moment, it isn't correct for either
> > private/internal libraries or public libraries; it's somewhere in
> > between.
> >
> > (In particular, seeing the Lintian overrides in the diff should probably
> > have been a warning sign.)
> >
> 
> During the first upload, the packaging was policy compliant as all
> libraries were sharing the same version. There was no override. The
> change in SO name for libzebra was done during a minor version
> update. At this time, I suggested to solve the problem by ignoring
> lintian instead of being overly complicated for a library without
> reverse dependencies. My bad.
> 

This was also due to me lacking the experience to solve this somewhat
complicated packaging issue. My apologies too.

FYI the version bump originated from this post to the upstream mailing
list[0], which shows upstream's somewhat relaxed attitude to ABI
stability. I guess this is understandable as the libraries are intended
to be private.

> >>  - removing libquagga0 and libquagga-dev and put the libraries in
> >>quagga-core and in /usr/lib/quagga. Not shipping the development
> >>files. This is a change that would likely to be accepted by the
> >>release team.
> >
> > I would recommend this route. As you say, splitting libquagga0 into
> > 5 library packages seems like overkill if nobody is going to use it.

Agreed.

[0]
https://lists.quagga.net/pipermail/quagga-dev/2016-December/033087.html

-- 
Regards,
Scott.


signature.asc
Description: PGP signature

Bug#856936: quagga: libquagga0 contains libraries with different SOVERSIONS

[Vincent Bernat]

 ❦ 10 mars 2017 09:29 GMT, Simon McVittie  :

>> I suppose that's why I am in copy (the other actions are pretty obvious
>> and I suppose Scott will apply them soon; I can also do that if he's
>> unavailable).
>
> The other reason I wanted to Cc you is because as sponsor, you were
> responsible for checking that the package split proposed by the
> maintainer was Policy-compliant. I would have expected a sponsor to
> query the current library packaging and not upload without changes,
> because as it stands at the moment, it isn't correct for either
> private/internal libraries or public libraries; it's somewhere in
> between.
>
> (In particular, seeing the Lintian overrides in the diff should probably
> have been a warning sign.)

During the first upload, the packaging was policy compliant as all
libraries were sharing the same version. There was no override. The
change in SO name for libzebra was done during a minor version
update. At this time, I suggested to solve the problem by ignoring
lintian instead of being overly complicated for a library without
reverse dependencies. My bad.

>> Acting like it is a
>> "0" versioning in the packaging shows there is no real guarantee in
>> that and is less invasive than patching the source.
>
> No, acting like it is a "0" version is saying that this library is fully
> compatible with all previous versions of libquagga0. This is clearly
> not true: anything with a DT_NEEDED entry for libzebra.so.0 would now
> fail to load, because there is no longer a libzebra.so.0 in the
> package.

That's the technical side. 0 can also mean that upstream doesn't
care about versioning (because that's also the default value).

> If a library offers development files and is placed on the default
> search path for the linker, then its maintainer is effectively saying
> it is a normal public shared library and will be managed accordingly,
> including package renames, ABI transitions and going through the NEW
> queue if it becomes necessary. If that isn't the intention, then the
> library shouldn't be on the default search path.
>


>>  - removing libquagga0 and libquagga-dev and put the libraries in
>>quagga-core and in /usr/lib/quagga. Not shipping the development
>>files. This is a change that would likely to be accepted by the
>>release team.
>
> I would recommend this route. As you say, splitting libquagga0 into
> 5 library packages seems like overkill if nobody is going to use it.
>
> If it is going to be treated as a public shared library in a future
> version, at that point you will have no choice but to split it (at
> least the parts whose SONAMES end with a nonzero version, but it
> would be safer to do the full split). But it sounds as though that
> is more appropriate for the future, or perhaps never, than for
> stretch.

OK with that.
-- 
Don't compare floating point numbers just for equality.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Bug#856936: quagga: libquagga0 contains libraries with different SOVERSIONS

[Simon McVittie]

On Fri, 10 Mar 2017 at 07:53:11 +0100, Vincent Bernat wrote:
> I suppose that's why I am in copy (the other actions are pretty obvious
> and I suppose Scott will apply them soon; I can also do that if he's
> unavailable).

The other reason I wanted to Cc you is because as sponsor, you were
responsible for checking that the package split proposed by the
maintainer was Policy-compliant. I would have expected a sponsor to
query the current library packaging and not upload without changes,
because as it stands at the moment, it isn't correct for either
private/internal libraries or public libraries; it's somewhere in
between.

(In particular, seeing the Lintian overrides in the diff should probably
have been a warning sign.)

> Acting like it is a
> "0" versioning in the packaging shows there is no real guarantee in
> that and is less invasive than patching the source.

No, acting like it is a "0" version is saying that this library is fully
compatible with all previous versions of libquagga0. This is clearly
not true: anything with a DT_NEEDED entry for libzebra.so.0 would now
fail to load, because there is no longer a libzebra.so.0 in the package.

There is nothing special about .so.0 from a stability point of view:
users of libglib2.0-0, libasyncns0, libbsd0, etc. presumably expect
them to behave like correct public shared libraries.

If a library offers development files and is placed on the default
search path for the linker, then its maintainer is effectively saying
it is a normal public shared library and will be managed accordingly,
including package renames, ABI transitions and going through the NEW
queue if it becomes necessary. If that isn't the intention, then the
library shouldn't be on the default search path.

>  - removing libquagga0 and libquagga-dev and put the libraries in
>quagga-core and in /usr/lib/quagga. Not shipping the development
>files. This is a change that would likely to be accepted by the
>release team.

I would recommend this route. As you say, splitting libquagga0 into
5 library packages seems like overkill if nobody is going to use it.

If it is going to be treated as a public shared library in a future
version, at that point you will have no choice but to split it (at
least the parts whose SONAMES end with a nonzero version, but it
would be safer to do the full split). But it sounds as though that
is more appropriate for the future, or perhaps never, than for stretch.

>But maybe the reporter of #705306 would find that not
>helpful (it's unclear if he is a user of the actual libquagga-dev or
>if he was just asking from a policy point of view).

The reporter of #705306 seems to have been primarily objecting to the
fact that quagga contained static libraries and headers from a
waste-of-space point of view (this was before the -dev was split out
at all). https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=705306#17
suggests that those libraries are considered experimental (although
that might have changed since 2013), and I didn't see anyone commenting
on that bug giving any indication that they would want to use any of
the libraries from outside src:quagga.

S

Bug#856936: quagga: libquagga0 contains libraries with different SOVERSIONS

[Vincent Bernat]

 ❦ 10 mars 2017 00:18 GMT, Simon McVittie  :

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

I suppose that's why I am in copy (the other actions are pretty obvious
and I suppose Scott will apply them soon; I can also do that if he's
unavailable). There are two (combined) reasons I asked for the override:

 1. It's quite unclear why upstream started to use a non-zero version
for the ABI numbering of libzebra. Maybe they will start enforcing
an ABI (it's the library that external projects should be the most
interested in using), maybe it's an oversight. Acting like it is a
"0" versioning in the packaging shows there is no real guarantee in
that and is less invasive than patching the source.

 2. The change is pretty recent and a major overhaul of the packaging
would have pushed past the deadline for the freeze (due to NEW). It
would have been difficult to explain why libquagga0 split in 5
packages is useful (no reverse dependencies).

I would favor the following corrective actions (in this order):

 - leaving libquagga0 package as is and fixing the other bugs

 - removing libquagga0 and libquagga-dev and put the libraries in
   quagga-core and in /usr/lib/quagga. Not shipping the development
   files. This is a change that would likely to be accepted by the
   release team. But maybe the reporter of #705306 would find that not
   helpful (it's unclear if he is a user of the actual libquagga-dev or
   if he was just asking from a policy point of view).
-- 
Truth is the most valuable thing we have -- so let us economize it.
-- Mark Twain


signature.asc
Description: PGP signature

Bug#856936: quagga: libquagga0 contains libraries with different SOVERSIONS

[Simon McVittie]

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

Bug#856936: quagga: libquagga0 contains libraries with different SOVERSIONS

[Andreas Henriksson]

Hello,

On Mon, Mar 06, 2017 at 01:51:58PM +0100, Andreas Beckmann wrote:
> Source: quagga
> Version: 1.1.1-1
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> 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.

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


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.

Advice on which alternative is preferred (by the maintainer) welcome!

Regards,
Andreas Henriksson

Bug#856936: quagga: libquagga0 contains libraries with different SOVERSIONS

[Andreas Beckmann]

Source: quagga
Version: 1.1.1-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

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
because libquagga0 ships the following files:

lrwxrwxrwx   1 root root 18 Jan 26 23:48 
/usr/lib/x86_64-linux-gnu/libfpm_pb.so.0 -> libfpm_pb.so.0.0.0
-rw-r--r--   1 root root   5832 Jan 26 23:48 
/usr/lib/x86_64-linux-gnu/libfpm_pb.so.0.0.0
lrwxrwxrwx   1 root root 16 Jan 26 23:48 
/usr/lib/x86_64-linux-gnu/libospf.so.0 -> libospf.so.0.0.0
-rw-r--r--   1 root root 616048 Jan 26 23:48 
/usr/lib/x86_64-linux-gnu/libospf.so.0.0.0
lrwxrwxrwx   1 root root 25 Jan 26 23:48 
/usr/lib/x86_64-linux-gnu/libospfapiclient.so.0 -> libospfapiclient.so.0.0.0
-rw-r--r--   1 root root  14176 Jan 26 23:48 
/usr/lib/x86_64-linux-gnu/libospfapiclient.so.0.0.0
lrwxrwxrwx   1 root root 21 Jan 26 23:48 
/usr/lib/x86_64-linux-gnu/libquagga_pb.so.0 -> libquagga_pb.so.0.0.0
-rw-r--r--   1 root root   5832 Jan 26 23:48 
/usr/lib/x86_64-linux-gnu/libquagga_pb.so.0.0.0
lrwxrwxrwx   1 root root 17 Jan 26 23:48 
/usr/lib/x86_64-linux-gnu/libzebra.so.1 -> libzebra.so.1.0.0
-rw-r--r--   1 root root 443792 Jan 26 23:48 
/usr/lib/x86_64-linux-gnu/libzebra.so.1.0.0

Please split the package to provide only one library per package
(or at least only one SOVERSION per package, if these are supposed
to not change independently).


cheers,

Andreas