Re: Packages violating policy 8.2
Aurelien Jarno <aurelien@aurel32.net> writes:
> 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
Oh, what package is that? I'm assuming kwave as that is the only one
with your email.
>>>> 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.
That might be the case for the packages that only have private share
libraries in public places. Reading policy 10.2 again it seems to
indicate that it exempts private libraries from 8.2. Is that correct?
In that case all but ~50 packages on the list might be ok, only
violating a "should" directive and they simply won't be multiarch
capable (and don't need to in all likelyhood).
>>>> 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.
If your package is not named lib<something> you don't have to fear a
bugreport from me. But it would be intresting to see just why it fails
when linked static anyway.
MfG
Goswin
Reply to: