Goswin von Brederlow wrote:
Aurelien Jarno <aurelien@aurel32.net> writes:Goswin von Brederlow wrote:Hi, Debian policy says: | 8.2 Run-time support programs | | If your package has some run-time support programs which use the | shared library you must not put them in the shared library | package. If you do that then you won't be able to install several | versions of the shared library without getting filename clashes. | | Instead, either create another package for the runtime binaries | (this package might typically be named libraryname-runtime; note the | absence of the soversion in the package name), or if the development | package is small, include them in there.
If no other package is supposed to link against your shared object then why not link it in static?Because it does not work?You have the source, you are compiling it. Is it beyond you to change it to static linking?
I already tried that, but the resulting binary does not work
If the library is only used for binary packages from the same source [which always get updated together] then why not put it in /usr/lib/package/ and make it not public?The problem is that it is not a default search path for the linker. And adding an rpath would simply violate the policy.Policy 10.2: | Shared object files (often .so files) that are not public libraries, | that is, they are not meant to be linked to by third party | executables (binaries of other packages), should be installed in | subdirectories of the /usr/lib directory. Such files are exempt from | the rules that govern ordinary shared libraries, except that they | must not be installed executable and should be stripped.[57] Yes, that requires the use of rpath. But policy does not forbid that for non system library dirs [it would be a contradiction to 10.2].I believe that if you have a shared object in (/usr)/lib then policy 8.2 _always_ applies. No excuses. Policy 8.2 is also a requirement for multiarch. For multiarch this will not only give conflicts between different soversions of a library but also between different architectures of a library.Maybe we can change the policy for those packages. I don't see why this could be a problem for multiarch. The library is only used by the binary which is the same package, so they are always in sync.libfoo:i386 contains /usr/bin/foo /usr/i486-linux-gnu/lib/libfoo.so.0 libfoo:amd64 contains /usr/bin/foo /usr/x86_64-linux-gnu/lib/libfoo.so.0 When both get installed dpkg will complain about trying to overwrite /usr/bin/foo.
Agreed, but we are speaking of binaries shipping private libraries, and I don't see why you want to install both version of it. Anyway other packages containing binaries and not libraries does not allow that.
Unless there is some reason not to I plan to file RC bugs at least against the 53 packages containing "lib" in the package name.Please see with the release team before doing that.Do you think they want to wave an exception to 8.2 for etch? It isn't that big of a deal to fix this.
Well, until know all my attempt do to static linking failed, the resulting binary was not usable. But patches are welcome.
-- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian GNU/Linux developer | Electrical Engineer `. `' aurel32@debian.org | aurelien@aurel32.net `- people.debian.org/~aurel32 | www.aurel32.net