[Discussion] Desktop Linux Platform Issues

[probonopd]

Discussion about Desktop Linux Platform Issues, continued from here.

The names of libraries should reflect the version as given by upstream.

This is not how library interface versioning is working. The number appended to the library name is increased whenever a non-backward compatible change to the library interface was made. If a new feature was added, but the library is still backwards compatible (can be used by apps built against older versions) only the minor version is bumped. That's also why glibc and libstdc++ are still soversion 6 (something I'm very thankful about).

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.

The minor version is not included in the actual soname of the ELF header. The versioning scheme of the actual project usually differs from the library versioning (and many projects also provide multiple libraries). That's why the library x265 version 2.5 doesn't have the soversion 2.5 or 25.

This still doesn't explain why the libarchive authors claim they cannot decide which version the so will have in a distribution.

libstdc++.so.6: Why is it necessary to still keep adding symbols to it, making software compiled against later versions fail on earlier versions?

Adding support for newer C++ standards (mostly I guess).

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.

_HarfBuzz: Bundling HarfBuzz seems to cause symbol lookup error: /usr/lib64/libpangoft2-1.0.so.0: undefined symbol: hb_buffer_set_clusterlevel.

Because of the prefixed "hb_" I'm assuming hb_buffer_set_cluster_level is a harfbuzz symbol and should be provided by libharfbuzz.

Which means what? How should the text on the wiki page be changed?

Image formats: Currently every distribution names these differently

I think the different naming in case of tiff, png and jpeg libraries is actually coming from different non-compatible version being available. There's i.e. libjpeg and libjpeg-turbo.

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.

The library versioning was a bit weird there in past, so libjpeg.so.62 (meaning 6.2 I think) is actually older than libjpeg.so.8.

Then every version newer than libjpeg.so.62 should have a number larger than 62. Why not continue with 80.

Or for libpng the soversion refers to the release branch (very uncommon for other libraries). So libpng.so.12 is from PNG 1.2.x, libpng.so.16 is from PNG 1.6.x, etc.

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.

I think tiff has a more regular soname versioning and some distros provide libtiff.so.4 along with libtiff.so.5 for backwards compatiblity.

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.

[Conan-Kudo]

@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.

[probonopd]

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:

1. Find out the highest soname number that is currently in use by any distribution
2. Bump the version of libarchive from 3 to that number plus (at least) one, say 42.0.0, with the next major ABI-breaking release
3. Ask distributions to call it libarchive.so.42 and file bugs if they don't
4. With the next ABI-breaking libarchive release, increase the libarchive version to 43.0.0, etc.

Would that be a sensible approach?

[Conan-Kudo]

@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:

• https://autotools.io/libtool/version.html

[probonopd]

Now we "only" need to convince upstream ;-)

[probonopd]

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.