[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Packages violating policy 8.2

Goswin von Brederlow wrote:

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.


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?

If no other package is supposed to link against your shared object
then why not link it in static?

Because it 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.

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.

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.

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.

  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian GNU/Linux developer | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net

Reply to: