On Sat, Dec 31, 2022 at 1:57 PM Tobias Frost <t...@debian.org> wrote:
> (sorry for being short worded, not having much time right now)
> Please note that library versioning has nothing do do with project versioning,
> don't conflate them… It is a sign of improper library versioning if the
> project has the same version as the library. IOW, so name versioning do
> not follow semantic versioning.
>
So it seems that there are like three versions to take into account
here(using liblog4cxx11):
1. The user-visible version(e.g. 0.11.0)
2. The version that the SO file has(e.g. liblog4cxx.so.11.0.0)
3. The ABI version of the library(e.g. 11)
As for the project version being the same version as the library, that
is the case with certain libraries:
robert@debian:/usr/lib/x86_64-linux-gnu$ apt-cache policy libqt5core5a
libqt5core5a:
Installed: 5.11.3+dfsg1-1+deb10u5
Candidate: 5.11.3+dfsg1-1+deb10u5
Version table:
*** 5.11.3+dfsg1-1+deb10u5 500
500 http://deb.debian.org/debian buster/main amd64 Packages
100 /var/lib/dpkg/status
5.11.3+dfsg1-1+deb10u3 500
500 http://security.debian.org/debian-security
buster/updates/main amd64 Packages
robert@debian:/usr/lib/x86_64-linux-gnu$ ls -l libQt5Core*
-rw-r--r-- 1 root root 1256 Mar 26 2022 libQt5Core.prl
lrwxrwxrwx 1 root root 20 Mar 26 2022 libQt5Core.so ->
libQt5Core.so.5.11.3
lrwxrwxrwx 1 root root 20 Mar 26 2022 libQt5Core.so.5 ->
libQt5Core.so.5.11.3
lrwxrwxrwx 1 root root 20 Mar 26 2022 libQt5Core.so.5.11 ->
libQt5Core.so.5.11.3
-rw-r--r-- 1 root root 5208360 Mar 26 2022 libQt5Core.so.5.11.3
If I'm understanding all of this correctly, using Qt as an example
there the user-visible version is 5.11.3, the SO version is 5.11.3,
and the ABI version is 5(since all Qt versions are ABI stable for
every minor release in their major).
> I still believe that the real name needs to be liblog4cxx.15.0.0, and this
> also matches my experience how it is done generally. I pretty please ask not
> to deviate from that, libraries are very easily made so that they are subtly
> break, and my experience shows that your are always best of by following
> established
> practices.
>
> BTW, I'm getting a (new) lintian warning [0]
> W: liblog4cxx15: package-name-doesnt-match-sonames liblog4cxx15.0.0
>
> readelf -a liblog4cxx.so.1.0.0.0 | grep SONAME
> 0x000000000000000e (SONAME) Library soname:
> [liblog4cxx.so.15.0.0]
>
> compare that to eg. of libpng:
> readelf -a /usr/lib/x86_64-linux-gnu/libpng16.so.16.39.0 | grep SONAME
> 0x000000000000000e (SONAME) Library soname: [libpng16.so.16]
>
> I think there is something broken, ENOTIME to investiate right now, probably
> SO version* is set to 15.0.0 instead of only 15.
>
> * sorry for the non-exact wording…
>
> [0] https://lintian.debian.org/tags/package-name-doesnt-match-sonames
>
> > Anyway, I'm going to do the following:
> > * Update the changelog for this new release
> > * Make sure the ABI dump is up to date(only needed for builds on
> > github, this is not in the release tarball)
> > * Merge next_stable into master and delete next_stable, so that master
> > becomes the new master
> > * Call a release vote
>
> Please lets first fix the SONAME issue… This is something which has a huge
> impact and having the need to have a Debian specific patch here would be
> really bad.
I'll make everything with the SONAME 15.0.0, since that follows what
we have been doing before. That lintian error is useful; now that I
know that you're getting that error, it makes sense to fix it on the
upstream end instead of having you fix that on yours.
-Robert Middleton
