Open probonopd opened 7 years ago
@probonopd Your libarchive issue in the wiki page is the result of upstream libarchive.
Quote from CMakeLists.txt:
# INTERFACE_VERSION increments with every release
# libarchive 2.7 == interface version 9 = 2 + 7
# libarchive 2.8 == interface version 10 = 2 + 8
# libarchive 2.9 == interface version 11 = 2 + 9
# libarchive 3.0 == interface version 12
# libarchive 3.1 == interface version 13
math(EXPR INTERFACE_VERSION "13 + ${_minor}")
This is not the fault of distributions. This is the fault of libarchive as they break the compatibility of the library on every major+minor and bump the interface each time. They're doing the right thing, but it breaks your use-case pretty hard.
Thanks @Conan-Kudo. I asked the libarchive project in https://github.com/libarchive/libarchive/issues/817,
Is there something this upstream project could do to enforce libarchive version 3 to be called libarchive.so.3 in distributions (rather some random int)?
The answer was:
There is really nothing we can do. Valid reasons for bumping the major version include ABI changes of the dependencies, e.g. OpenSSL. The availability of libarchive.so is a packaging choice, many Linux distributions like to split them off into a separate devel package.
So the right course of action would be, imho:
libarchive.so.42
and file bugs if they don'tWould that be a sensible approach?
@probonopd Absolutely. The right way to fix this is to bump to new higher number and start following the proper shared object versioning scheme.
More info:
Now we "only" need to convince upstream ;-)
On the libarchive issue, relevant discussion at https://twitter.com/probonopd/status/932194484800118784. @alexlarsson:
I don’t actually know, but given past Debian experiences my guess is that upstream broke abi but didn’t bump soname, and Debian bumped the soname to “fix” this according to Debian standards.
I’m sure you can verify this by looking at the deb history.
Discussion about Desktop Linux Platform Issues, continued from here.
I understand this. But who makes non-backward compatible change to the library interface and hence decides about the library version? The upstream authors, hopefully.
This still doesn't explain why the
libarchive
authors claim they cannot decide which version the so will have in a distribution.C++ as a programming language should only change concerning the input (source code), but the output (binaries) should hopefully stabilized by now to a degree that wouldn't make half-annually
glibc
changes necessary.Which means what? How should the text on the wiki page be changed?
Then distributions should decide on a common standard, agree on using just that, and porting over the advantages of the libraries which have "lost". I had luck, in the past, by merely renaming libraries though, so I doubt they are all really that different.
Then every version newer than
libjpeg.so.62
should have a number larger than 62. Why not continue with 80.Hold on. I thought major versions should only be used when the ABI breaks. But since 1.2 to 1.6, according to semver, does not break ABI, they all should have the same so version. If they do break ABI, then they should not be called 1.2 and 1.6 but 12, .., 16.
That's what should be done for all the basic components of the Desktop Linux Platform: Increase the major number only when the ABI breaks, try to do this as seldomly as possible (e.g., no more than every 5-7 years), and when it happens, call the previous version "deprecated" but all distributions continue to provide the deprecated version in the default installation for at least a determined period of time, so that developers have enough time to switch over.