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