Re: Standard homework around SONAMEs and library file names
On Tue, Dec 1, 2009 at 6:29 PM, Thibaut Paumard <mlotpot.news@free.fr> wrote:
> Out of curiosity and also to help a library's new upstream reach the
> archive, I am learning about SONAME handling in Debian packages. I have read
> [1] but still could use direct advice.
> [1]
Not sure what [1] is, but I guess you mean libpkg-guide?
> I am working on a library named libfooN (library name ends in a digit).
> Upstream doesn't provide shared library, so no upstream SONAME.
Please talk to upstream about fixing this.
> - I don't get why the .so.1.x.y file is needed. If it is, should it be
> related to the package version or to the SONAME?
The .so.1.x.y is where the library executable code is stored. IIRC the
.x.y is so that multiple versions of the same ABI of the library can
be installed at the same time. The filename is derived from the
SONAME. The package version is unrelated to the SONAME, some upstreams
keep the SONAME and version number related.
> - Should the next SONAME be libfooN.so.2, libfooN.so.1.1, libfooN.so.1.X
> (matching new upstream version), or even libfooN.so.debian2 is case upstream
> suddenly decides to use SONAMEs themselves?
libfooN.so.debian1. Since there was no debian1 SONAME yet, you can use
that. debian2 would be fine too. Whenever you have to change or add a
SONAME, it is a good idea to use a Debian-specific one to avoid
clashes with upstream and other distros.
> - Even if the -dev package is currently named libfooN-dev, I guess it is
> better to use the SONAME in the next package: libfooN-SOVERS-dev, so that
> the few packages which currently Build-Depend on it don't FTBFS?
The -dev package should not contain the SONAME, only the API number if
any (N in this case). See #493951 for a Debian release manager's
perspective on this issue.
> - If the SONAME contains the string "debian", should it be reflected in the
> package names? (i.e.: libfooN-debian2)
Yes, see this command from libpkg-guide:
http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#naminglibpkg
> - Should an additional upload of the previous version (1.x.y) be done in
> order to introduce libfooN-1-dev?
That is an additional transition for no real benefit. I'd say just
upload the 2.x.y version.
> - Should the source package name also contain the soname?
No, I don't think so. Just name it like the upstream tarball.
> To complicate things a bit further, the Debian package is stripped of DFSG
> incompatible symbols. Usually, I would code this information in the package
> version (libfooN-1_1.x.y+dfsg-1). Does it needs to enter the SONAME as well?
> (That would be an additional reason to use an SONAME such as .so.debian2).
If you can make the DFSG-incompatible symbols stubs that return an
error indicating that they are not implemented, I think that would be
good for compatibility. This depends on if upstream has a way to
indicate this. If you cannot, then it would be better to strip them
and go with a Debian-specific SONAME. The Debian-specific SONAME
doesn't really need to indicate the reason for this. Obviously you
need +dfsg in the version number though.
Please talk to upstream about these symbols, perhaps they could do one of these:
strip out the symbols entirely
move the symbols to a plugin
relicense the code under a DFSG-compatible license.
PS: when you're creating the packaging, please take #501878 into account.
--
bye,
pabs
http://wiki.debian.org/PaulWise
Reply to: