Arch Linux User Repository

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

@oxalin, I'd also like to suggest and ask that you remove the hardcoded versioned dependence on openjpeg2.

That makes Arch system upgrades a pain when there is a newer openjpeg2 in the Arch repo while lib32-openjpeg2 has not yet been bumped.

I would recommend a middle ground, though:

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

That way, Arch users would have no issues upgrading to the newer repo version of openjpeg2 while the lib32 version is not bumped.

I know that is not ideal, because then the dependents of lib32-openjpeg2 can potentially use newer headers of openjpeg2 than the version of the installed lib32-openjpeg2 when building the package.

But such a scenario rarely causes problems, because header upgrades are usually not drastic (typically upstream devs just mark some definitions deprecated for several releases before dropping them completely). Also, such potential but rare problems would only affect a limited number of user-built lib32 AUR packages.

On the other hand, hardcoding the version of openjpeg2 to lib32-openjpeg2 will prevent users from upgrading openjpeg2 but typically will not prevent them to upgrade ffmpeg or gstreamer. Then, the newer versions of those dependent packages would be incompatible with the non-latest openjpeg2 in case of an upstream SO version bump of the latter, breaking ffmpeg and/or gstreamer and a lot of downstream libraries / apps installed from the Arch repos.

Allowing the 'depends= (repo-package)>=(lib32-version)' constraint would lead to the far lesser evil according to the reasoning explained above. It would prevent breaking the runtime functioning of any Arch repo package because of the not yet bumped lib32 AUR package.

~~Since the v2.5.0 update is not very much, I made this patch. It SHOULDN'T cause any problems.
Keep in mind that this is an unofficial patch.

After using this patch, don't forget to update the 64-bit version.~~

DELETED

EDIT: The official one is updated.

Please update ASAP. This package for some reason has a dependency on the 64-bit openjpeg2, which has been updated to 2.5.0 on the main Arch repo a few days ago.