Re: Packages violating policy 8.2
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.
>>
>
> [snip]
>
>> For some (or a lot?) packages the maintainer may claim that they
>> don't
>> contain public shared libraries, only package internal shared objects.
>> Then why do you have shlib files [only spot checked for that]?
>
> Have you verified which packages ship an shlib and which not?
As I said I only spot checked for the shlib files.
>> 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?
>> 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.
>> 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.
>> libc6 GNU Libc Maintainers <debian-glibc@lists.debian.org>
>
> For this one, please talk with the ftpmasters. Such a change has
> already been done, but rejected from the NEW queue.
With the reason that splitting essential packages has to be discussed
first. That has been done now for libc6 and has to happen e.g. for
apt. I agree that this will need extra care for essential packages but
they still violate policy. The bug remains and I hope ftp-master can
be convinced to abide by policy too.
MfG
Goswin
Reply to: