Bug#700759: Shared library policy on private libs
On Sat, Feb 16, 2013 at 08:24:09PM -0500, Phillip Susi wrote:
> Package: tech-ctte
>
> I filed bug #700677 because ntfs-3g has a shared library that ubuntu's
> testdisk links to, but it does not follow the SONAME rules. It seems
> that upstream breaks ABI on every release, and the maintainer feels
> that the library is not intended for other packages to link to, and
> therefore, does not have to comply with section 8.1 of the policy manual.
>
> I believe that a strict and literal interpretation of the language of
> section 8 means that whether you intend the library for other packages
> to link to or not, if it is placed in a directory on the default
> library search path, it is bound by section 8.1. The statement in
> question is:
>
> "This section deals only with public shared libraries: shared
> libraries that are placed in directories searched by the dynamic
> linker by default or which are intended to be linked against normally
> and possibly used by other, independent packages."
>
> The use of the word OR there means that whether or not you intend the
> lib to be linked against normally and used by other packages, if it is
> in a directory on the library search path, then section 8.1 applies.
I think that section 8.1 applies. It seems to even match both
cases of the or since it:
- Actually has an soname
- Is shipped in a dir the dynamic linker searches
- You say other binaries link against it.
- Has a ntfs-3g-dev package
> Also there should be something in
> place in the debian build system to make sure that linking to such
> private libraries either is flagged as an error, or generates a
> dependency on the exact version of the library package that the
> linking package was built against, in order to prevent packages from
> being installable, but unrunnable due to a newer version of the
> private library with a different SONAME being installed.
What could be done is that the shlibs file sets up a strict version
dependency. It currently says:
libntfs-3g 837 ntfs-3g
udeb: libntfs-3g 837 ntfs-3g-udeb
That is without any version at all, and it really should have
a version there. I think more than 99% of the packages should
have a version there, and it seems lintian doesn't warn about it.
An other way to avoid the problem is only providing a static
version of the library, but we want to avoid that.
Yet an other solution is to provide an API that is stable,
and put that in a library with a fixed soname and move the
rest to a private library.
Kurt
Reply to: