[Discussion] Desktop Linux Platform Issues

Discussion about [Desktop Linux Platform Issues](https://github.com/AppImage/AppImageKit/wiki/Desktop-Linux-Platform-Issues), continued from [here](https://github.com/darealshinji/vlc-AppImage/issues/1#issuecomment-321091893).

> _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](https://sourceware.org/glibc/wiki/Glibc%20Timeline) `glibc` changes necessary.

> _HarfBuzz:
> Bundling HarfBuzz seems to cause symbol lookup error: /usr/lib64/libpangoft2-1.0.so.0: undefined symbol: hb_buffer_set_cluster_level._
>
> 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.