jxrlib: switch to maintained fork, ship pkgconfig. freeimage: unbundle libraries, fix ftbfs

[JkktBkkt]

On master, both of these packages fail to build.

Testing the changes

I tested the changes in this PR: briefly — successfully built reverse dependencies of both of these packages with enabled testsuites (where available) on: x86_64, x86_64-musl, i686 and cross

• occt
• libogre
• SLADE
• EmulationStation
• kew
• MEGAsdk
• calibre (cross and i686 disabled, marked broken)

Local build testing

• I built this PR locally for my native architecture, x86_64
• I built this PR locally for these architectures (marked crossbuilds with *):
  • x86_64-musl
  • i686
  • armv6l *
  • armv6l-musl *
  • armv7l *
  • armv7l-musl *
  • aarch64 *
  • aarch64-musl *

Notes

These changes are based on arch and fedora packages, had to edit in the pkgconfig for jxrlib (so it can be found in cross builds).
Proper cmake support for jxrlib is planned by the maintainer of this fork, but hasn't been pushed yet, so this PR uses a third-party written CMakeLists.txt still.

I tried using cmake build style for freeimage from this fork but it appears that freeimageplus wrapper is not being built in that case, and is not maintained.

[ahesford]

These changes are not acceptable for a couple of reasons:

• jxrlib never should have been packaged. We don't vendor cmake rules just to use a different build system. We don't pick arbitrary forks of upstream projects or switch willy-nilly between arbitrary forks because one offers some features we desire. The right fix for this package is to remove it.
• A 750-line patch to de-vendor libraries is an inappropriate amount of change to an upstream project and is going to make the package exceedingly difficult to maintain. Take this work to the upstream maintainer.

What is the provenance of the libraw patch? Patches that change program behavior should document their origin and acceptance upstream, preferably with a git email header providing commit details.

[JkktBkkt]

on jxrlib:

• I agree that vendoring cmake rules is not a great idea.

• It was added as part of this calibre: update to 4.14.0. #20793 PR updating calibre, and it has been used there ever since. It's still listed as a necessity for the check phase, so from my perspective, removing it is undesirable. Leaving it in an unbuildable state where even the source repository is no longer accessible is pretty bad too. (Available mirror dates last changes to 9 years ago)

• The chosen fork is in use in OpenSUSE, OpenMandriva and Arch.

• There is an alternative, used in Debian-based distributions, maintained here.

• I did run the test suite of calibre after removing jxrlib from it's makecheck and noticed no issues, so perhaps it is no longer used there.

• However, it is still bundled in freeimage (and fails to build without windows libraries), which is used in several packages (noted which above, in the build testing section).

on Freeimage:

• I would gladly take the unbundling patch to the maintainer, but there hasn't been much activity there as of late and the patches to remove bundled libraries have been in existence since at least 13 years ago, i.e. this: https://build.opensuse.org/package/show/openSUSE:Factory/freeimage?rev=1

• The particular version of the patch used here was taken from arch (which took it from fedora), where it has been updated when necessary since september of 2015. See: FreeImage-3.17.0_unbundle.patch

• It is their design decision to use bundled versions as stated by the author in 2010: https://sourceforge.net/p/freeimage/bugs/130/#107d

• Keeping everything bundled, as I know you're aware, is a pretty poor decision

on libraw patch in freeimage:

• I forgot to put those details in when fetching the patch. Pushed with links, here they are duplicated: 1842 and 1895. As you can see, not much to go off of in terms of commit messages or explanations.

• The alternative that I haven't explored for these patches is to use the trunk of freeimage from sourceforge, which is done by OpenSUSE, fedora, and probably other distributions too (haven't looked into it). That would require more timely maintenance of unbundling patch, but the unbundle.patch from fedora is currently based on 1909 SVN revision, and from briefly looking at what changed in 1910/1911 revisions (Bundled LibTIFF update), it should probably apply clean or with minimal changes.

[ahesford]

A library built from a fork of the official upstream just to satisfy a check dependency for calibre is not worth keeping around. Just get calibre to pass tests without jxrlib and remove the unneeded package.

I don't care if we all agree that bundling system libraries in freeimage is a poor decision. The author of freeimage has considered this problem and has actively decided against it. We don't override upstream design decisions because we don't like them. We don't override upstream design decisions because other distributions prefer to. As you can see, the change to override this upstream decision is extensive and difficult to maintain. It's not going to happen here. If the design of freeimage is causing problems, we should consider removing freeimage from our package tree, not pruning it to suit our arbitrary tastes.

[JkktBkkt]

I don't think it should be called pruning when it's changing stuff like UINT64 to uint64 in the patch, largely one line of difference per snippet. There's over 40 patches >500 lines long, and I fail to grasp what makes this different compared to, i.e. srcpkgs/contour/patches/fmt-11.patch or srcpkgs/fbreader/patches/qt5.patch

In the 7, almost 8 years of existing of the unbundling patch under current name, it barely changed at all:

Here's when the 3.18 version of it was introduced: https://src.fedoraproject.org/rpms/freeimage/blob/fc41dd11c6506ce4b5372a61c7ac41263e25c5f9/f/FreeImage_unbundle.patch

10 years if we compare against the 3.17 one: https://src.fedoraproject.org/rpms/freeimage/blob/fc41dd11c6506ce4b5372a61c7ac41263e25c5f9/f/FreeImage_unbundle.patch

This does not seem difficult to maintain, though, sure, it is harder than bumping a package when new version gets released (though it simply doesn't here)

consider removing freeimage from our package tree

It is used directly or indirectly in all these: libogre cegui TSC occt dune3d freecad gmsh horizon kicad librepcb python3-occ
Personally, I don't require the use of any of them, but I don't think purging them all would be a great addition.

I'm not suggesting we follow other distributions just for the sake of it, I'm trying to solve a problem and have found a solution that appears to me to be moderate in the changes it requires, good in compatibility, and wide-spread enough that it becomes an acceptable path forward for the users.
And it's not because I don't like bundled libraries either. Personally I probably wouldn't even notice that being the case, but the package is failing to build and does not get new releases in upstream, which is simply inappropriate given the amount of issues found and fixes pushed since last release, with the latest revbump here being in 2022.

[JkktBkkt]

Looking further into the possibility of removing freeimage, it appears that

occt can have it disabled (and does so by default nowadays)
kew: no longer uses it
SLADE: dependency has been replaced by wxWidgets and libwebp sirjuddington/SLADE@e95de2d

libogre: suggests using a fork, patching or their rust codepaths instead, can be seen here: OGRECave/ogre@1c447e0
EmulationStation still uses it and suggests updating downstream. See here: RetroPie/EmulationStation#871
MegaSDK uses it from vcpkg: meganz/sdk@d5fe1fa

I also found python3-imageio (has freeimage in dependencies) and python3-scikit-image (depends on python3-imageio), both of which you maintain and I initially missed.
Would removing freeimage be a problem for either of those two?

Please advise.

[ahesford]

I don't have a problem with the libraw patch or changing typedefs to support modern compilers. The large patch you've added seems to be an omnibus that solves a few problems and should be split into functional units.

I have a big problem overriding explicit upstream decision not to use the censored libraries. When upstream makes a decision with which we don't agree, the choice is to accept the difference or refuse to package the software.

Other examples, like the qt4 -> qt5 patch you note, were most likely made to accommodate our packaging decision to remove qt4. There is no similar packaging concern with freeimage. Furthermore, if the authors of that package explicitly declared their objection to supporting qt5, I'd make the same argument there.

We should

• Remove freeimage dependencies everywhere possible (I've already dropped it from imageio)
• Patch freeimage as little as possible to get it to build and satisfy the remaining dependents
• Remove the jxr package, it wasn't suitable to begin with
• Consider how we might remove the remaining dependencies on the apparently dead freeimage, which may including dropping those dependents