Arch Linux

DaVinci Resolve (packets davinci-resolve, davinci-resolve-beta, etc.) does not start anymore with the error:
"/opt/resolve/bin/resolve: error while loading shared libraries: libbz2.so.1: cannot open shared object file: No such file or directory"
Only manually adding the since 1.0.7 missing symlink makes the app start again e.g. via
$sudo ln -s /usr/lib/libbz2.so.1.0.7 /usr/lib/libbz2.so.1

To get DaVinci Resolve packages work again the now missing symlink should be added to the libbz2 package again.

libbz2.so.1 was present in previous package. Also present on other distributions, so we should re-add the .so.1 symlink.

Just because Fedora changes the soname to something that doesn't exist anywhere else, potentially screwing themselves and everyone else over, doesn't mean we should support this hack. I already talked to the Dev that removed it, it's gone.

The libbz2.so.1 soname existed on Archlinux in 1.0.6, exists on debian and several other distributions. Why remove something and break backwards and cross-distro compatibility?

It was not the soname in Arch. Never has been. It does not break backward compatibility, it only breaks compatibility with binaries from Fedora because they made a downstream soname change.

Check the changes in revision 3e8d4b6d8ec327a3a2248be4188a704ec53c2a68, the symlink did exist in 1.0.6.

According to readelf on 1.0.6 and 1.0.7: 0x000000000000000e (SONAME) Library soname: [libbz2.so.1.0]

So the soname to link to is .so.1.0, not .so.1. The link existed for compatibility reasons only.

I never said the symlink didn't exist, I said the soname didn't exist in response to your statement that it did. The link was intentionally removed, and should be taken care of in packages that need it.

> The link was intentionally removed, and should be taken care of in packages that need it.

How is that going to work? Lots of pieces of software require a symlink that is readily provided in a single package...

I agree with Allan.
Furthermore, if several depending packages have to provide the symlink by themselves, how are their installers supposed to not to interfere with each other?
Consider packages A and B, which both require the symlink: When installing B after A, B's attempt to create the symlink will fail.
Even if you teach each depending package to ignore that error, when you then remove e.g. A, the symlink will be removed in the process. As a result, B will not work anymore.
How is this resulting issue to be avoided, or is there some reference counting mechanism provided by the package manager for symlinks?
(And even if there is, as Allan said, everything will be made unnecessarily complicated that way, I assume.)

There is no "lots of pieces of software" involved here. It has already been solved in davinci-resolve-beta, where they have a section for symlinks like this in the PKGBUILD, if you want to see how it works.

https://people.gnome.org/~federico/blog/preparing-the-bzip2-107-release.html

The soname will be changing to libbz2.so.1 in the next release, moving the upstream soname in line with Fedora and openSUSE. This is already committed upstream:

https://gitlab.com/federicomenaquintero/bzip2/commit/277548b072c3d8cd1c3bbe38a09f3acbe52b6846

Having other software provide the libbz2.so.1 in the meantime is a recipe for conflicts later.

It was agreed with the maintainer of this package on IRC to provide this symlink, with appropriate documentation in the PKGBUILD.

Although that may be a different "official" bzip2 maintainer.

@eschwartz upstream agreed that Fedora "idiots" fixes were right and the soname used by bzip2 was a bizarre thing that must change. Keep in mind that this software was unmaintained for a decade and this was the only reason that change wasn't upstreamed much earlier.

I hope some day you reconsider calling others "idiots".

@MichelKoss1,

The problem is that Fedora should not have done so in a manner that completely and utterly fragmented the Linux world. If the software is unmaintained, they have the ability to do the exact same thing that the very recent new upstream for bzip2 did: reach out to the bzip2 author and ask to adopt the project. If they don't agree or cannot be reached, then there is always the option to fork and take over maintenance anyway. This would have actually been something useful to bring to the world, because the result would be what (surprise) we have now -- someone interested in taking care of bzip2, coordinating bug fixes and CVE fixes and providing a build system everyone can agree on.

The reason the Fedora bzip2 soname was idiocy is because they *broke software* by their implementation. The soname is not harmful *at all* and the only justification that Fedora had is "it looks less pretty", and the rationale for the new upstream choosing to adopt Fedora's soname is to *fix the broken situation where Fedora's boutique soname disagrees with everyone else*.

It was, is, and will always be utterly, irredeemably, stupid.

And okay, fine, since it is apparently changed upstream it's not fundamentally terrible to backport that functional effect to our current package. I happen to not really think there is much point in caring, since there is no "recipe for conflicts later" unless some fool AUR package tries to add one in /usr/lib (davinci-resolve-beta has its own /opt/resolve/libs/libbz2.so.1 for this) but whatever.

The fact that we are backporting a soname compatibility shim does not detract from the fact that it is Fedora (the distro itself, not their bzip2 package but the mindset that made them think it is okay to play this sort of monkey game that hurts everyone) that is "a bizarre thing that must change".