Standard homework around SONAMEs and library file names
Dear mentors,
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]
I am working on a library named libfooN (library name ends in a
digit). Upstream doesn't provide shared library, so no upstream SONAME.
The source package builds:
- libfooN-1 which contains libfooN.so.1.x.y and libfooN.so.1 (a link)
- libfooN-dev which contains libfooN.a and libfooN.so (another link)
- fooN-utils.
The SONAME in libfooN.so.1.x.y is libfooN.so.1 1.x.y is the upstream
version currently in the archive. I want to package a new upstream,
1.X, which has incompatible API (and hence ABI) changes.
Now for the questions:
- 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?
- 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?
- 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?
- If the SONAME contains the string "debian", should it be reflected
in the package names? (i.e.: libfooN-debian2)
- Should an additional upload of the previous version (1.x.y) be
done in order to introduce libfooN-1-dev?
- Should the source package name also contain the soname?
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).
Thanks for reading, I hope I was clear enough :-)
Best regards, Thibaut.
Reply to: