Re: How package a binary library with unversioned soname?

[Russ Allbery <rra@debian.org>]

Nikolaus Schulz <microschulz@web.de> writes:

> I am packaging printer drivers from Canon, see [1] for the ITP and some
> notes about that very peculiar, awkward beast.  These drivers are only
> partly free software, they come with non-free, binary-only libraries.
> While this is bad enough, unfortunately the libraries have unversioned
> sonames, and I see zero chance to have upstream (Canon) fix this.

> So, one cannot produce valid shlibs files for these libraries.  But
> these are required by policy.  That is, as Steve Langasek has pointed
> out in [2], the policy de-facto requires libraries to have versioned
> sonames.

Policy doesn't require valid SONAMEs for private shared libraries specific
to a particular application.  The SONAME requirement is to allow
reasonable handling of library changes and upgrades of packages that built
against the libraries, which only applies if the libraries are in a
separate package from the programs that use them.  If you have a program
that contains some binaries linked with private libraries, Policy doesn't
really care what those libraries are like provided that they're
self-contained within that package and are installed in a subdirectory of
/usr/lib.

See Policy 10.2, specifically:

    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.

It sounds like you should try to treat these upstream shared libraries
under this exception as private libraries for the binaries built by this
package rather than trying to use them as first-class shared libraries.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>