Arch Linux User Repository

Consider adding -DBUILD_CODEC=OFF -DBUILD_TESTING=OFF to significantly speed up the build by skipping the compilation of binaries that are removed during installation. Also, it might be better to switch to -DCMAKE_BUILD_TYPE=None to prevent -O3 from being appended to the build flags. Additionally, VERBOSE=1 might be unnecessary.

@martinf99: fixed, thanks. I had gone over the build process too fast and I missed it. Using CMAKE_INSTALL_LIBDIR is more consistent anyway.

Latest version uses wrong /usr path for cmake modules and the lib. For some reason it tries to install the so file into /usr/lib instead of /usr/lib32

-DOPENJPEG_INSTALL_LIB_DIR does not seem to do anything anymore use -DCMAKE_INSTALL_LIBDIR instead

@MarsSeed: This package can be kept around (or not), your comment mostly concerns ffmpeg.

This package is up to date with the latest available release. However, I can update it so it mirrors the latest changes applied on the native package.

I suggest to drop this unneeded, slower JPEG2000 codec from lib32-ffmpeg instead of aligning it with repo's changes.

The FFMPEG built-in codec should be used, and is the preferred one.

Never mind. I've realized that none of the consuming 32-bit libraries have any realistic use cases for the marginal JPEG 2000 file format.

(Also this format is too new for it to be stuck in the 32-bit world on desktop, but also too old because now even WebP is widely supported in everyday software and even hardware, whereas this only has a fancy name but is without any actual consumer base.)

I've left comments in all relevant package pages with my proposal that maintainers consider dropping this dependency.

GStreamer and FFMPEG would only use it for JPEG2000 video streams, but FFMPEG has an internal codec for it as well, which is even faster.

Other than that, gegl and poppler are only used by some legacy 32-bit scanner software on AUR. But scanners never supported this codec.

Games, interactive encyclopedias and other desktop multimedia content applications also don't used this format.

Seems repo's jbigkit is a static library for some reason, and it gets statically linked to libtiff (see FS#77224). And libtiff's pkg-conf file refers to it as private dependency.

After some consideration, I lean towards recommending the removal of libtiff support altogether from lib32-openjpeg2. The only library that some scanner drivers might use is lib32-gegl via lib32-gimp, which uses lib32-libtiff directly - no need for openjpeg2 to also support libtiff.

Edit 1: also (lib32-)sane uses (lib32-)libtiff directly (without jbigkit as makedepend).

Edit 2: (lib32-)gegl also does not need (lib32-)jbigkit to use libtiff.

In 2022, repo added jbigkit from 2014 as makedepend in the latest version of openjpeg2. But seems highly dubious, as JBIG has zero things to do with JPEG, and openjpeg2 build configuration never refers to jbig, and never did so in the past.

I am AFK nowadays so I cannot verify my hunch, but it would be good if you could take a look; lib32-jbigkit could be dropped from AUR if it was truly unneeded by this package.

Thanks for the AUR! Came to pitch in to say that i had to edit the build : The part

[code]

depends=("${_pkgbasename}>=${pkgver}"

[/code]

i had to add a specifi version number

[code]

depends=("${_pkgbasename}>=2.4"

[/code]

as the openjpeg2 64bit version is still on 2.4 for me.

Best regards, and sorry for the mess, can't figure out how to use the [code] tag for the life of me

@MarsSeed: I've been updating packages to be more flexible on native package's version dependency. So I updated exactly as you suggested. :)