Search Criteria
Package Details: lib32-openjpeg2 2.5.3-2
Package Actions
Git Clone URL: | https://aur.archlinux.org/lib32-openjpeg2.git (read-only, click to copy) |
---|---|
Package Base: | lib32-openjpeg2 |
Description: | An open source JPEG 2000 codec, version 2.5.3 |
Upstream URL: | http://www.openjpeg.org |
Licenses: | MIT, BSD-2-Clause |
Submitter: | oxalin |
Maintainer: | oxalin |
Last Packager: | oxalin |
Votes: | 18 |
Popularity: | 0.090849 |
First Submitted: | 2016-04-25 23:48 (UTC) |
Last Updated: | 2025-01-18 15:29 (UTC) |
Dependencies (9)
- lib32-gcc-libs (lib32-gcc-libs-gitAUR, lib32-gccrs-libs-gitAUR, lib32-gcc-libs-snapshotAUR)
- lib32-glibc (lib32-glibc-gitAUR, lib32-glibc-linux4AUR, lib32-glibc-eacAUR)
- lib32-lcms2
- lib32-libpng
- lib32-libtiff
- lib32-zlib
- openjpeg2 (openjpeg-gitAUR)
- cmake (cmake-gitAUR, cmake3AUR) (make)
- graphviz (make)
Latest Comments
« First ‹ Previous 1 2
MarsSeed commented on 2022-05-19 19:17 (UTC) (edited on 2022-05-19 19:28 (UTC) by MarsSeed)
@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:
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.
Aozora commented on 2022-05-19 11:33 (UTC) (edited on 2022-05-21 14:15 (UTC) by Aozora)
~~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.~~
EDIT: The official one is updated.
RAMChYLD commented on 2022-05-18 18:25 (UTC) (edited on 2022-05-18 18:26 (UTC) by RAMChYLD)
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.
oxalin commented on 2021-01-08 18:55 (UTC)
@sl1pkn07: thanks for the cleanup suggestion. I incorporated a big part of it in the latest update.
sl1pkn07 commented on 2021-01-03 18:09 (UTC) (edited on 2021-01-03 18:28 (UTC) by sl1pkn07)
oxalin commented on 2016-09-30 04:47 (UTC)
J5lx commented on 2016-09-26 04:03 (UTC)
« First ‹ Previous 1 2