Search Criteria
Package Details: exiv2-git 0.27.4.RC2.r247.gc7a41230f-2
Package Actions
Git Clone URL: | https://aur.archlinux.org/exiv2-git.git (read-only, click to copy) |
---|---|
Package Base: | exiv2-git |
Description: | Exif, Iptc and XMP metadata manipulation library and tools |
Upstream URL: | https://github.com/Exiv2/exiv2 |
Licenses: | GPL2 |
Conflicts: | exiv2 |
Provides: | exiv2, libexiv2.so |
Submitter: | jcjgraf |
Maintainer: | jcjgraf |
Last Packager: | jcjgraf |
Votes: | 1 |
Popularity: | 0.000000 |
First Submitted: | 2021-05-20 08:42 (UTC) |
Last Updated: | 2021-05-20 11:01 (UTC) |
Dependencies (8)
- curl (curl-quiche-gitAUR, curl-http3-ngtcp2AUR, curl-gitAUR, curl-c-aresAUR)
- expat (expat-gitAUR)
- gcc-libs (gcc-libs-gitAUR, gccrs-libs-gitAUR, gcc11-libsAUR, gcc-libs-snapshotAUR)
- gettext (gettext-gitAUR)
- zlib (zlib-ng-compat-gitAUR, zlib-gitAUR, zlib-ng-compatAUR)
- cmake (cmake-gitAUR) (make)
- git (git-gitAUR, git-glAUR) (make)
- gtest (googletest-gitAUR) (make)
Required by (86)
- ansel-git (requires exiv2)
- art-rawconverter (requires exiv2)
- art-rawconverter-git (requires exiv2)
- darktable-cr3 (requires exiv2)
- darktable-git (requires exiv2)
- digikam-git (requires exiv2)
- digikam-without-akonadi (requires exiv2)
- ffdiaporama (requires exiv2)
- filmulator (requires exiv2)
- geeqie-git (requires exiv2)
- geeqie-gtk2 (requires exiv2)
- geeqie15 (requires exiv2)
- gegl-git (requires exiv2) (make)
- geotagging (requires exiv2)
- gerbera-mysql (requires exiv2)
- gerbera-nosystemd-git (requires exiv2)
- gimp-lensfun (requires exiv2)
- gnome-commander-git (requires exiv2)
- gpscorrelate-git (requires exiv2)
- gpxtools-git (requires exiv2)
- Show 66 more...
Latest Comments
MarsSeed commented on 2023-06-30 16:14 (UTC)
Which means that the generated SO version will also be bogus when building the main branch.
MarsSeed commented on 2023-06-30 16:12 (UTC)
Btw since this commit
350b7b0
in 2021, they bumped the main branchCMakeLists.txt
file's project version to a bogus1.00.0.9
, and they only downgrade that version when branching off to a new release version. :/MarsSeed commented on 2023-06-30 16:06 (UTC)
And now I have a new idea that finding the latest release version would best be automated in a pkgver() implementation. Though it would be fairly complicated to get it right and robust.
MarsSeed commented on 2023-06-30 15:47 (UTC)
It turns out that my version-pinned
pkgver()
implementation is buggy. I will get back to you once I had time to sort this out.MarsSeed commented on 2023-06-30 15:16 (UTC)
Oh, and if in the future the project returns to correctly tagging the main branch, then there will be no need at all to change my recommended
pkgver()
.(If, however, they continue this wrong tagging practice, then from time to time you'll need to manually bump the pinned version and corresponding one-newer main branch commit.
But seeing their past release cadence, you would need to do this maybe ½-2 times per year.)
MarsSeed commented on 2023-06-30 15:06 (UTC)
If you added the
pkgver()
I recommended to you in my last comment, then it would make sense to declare versioned provides for exiv2:MarsSeed commented on 2023-06-30 15:02 (UTC) (edited on 2023-06-30 15:12 (UTC) by MarsSeed)
Hm, actually you might want to use an even more customized
pkgver()
, like the one I created here.With this, you can declare the following in the beginning of your PKGBUILD:
The values I entered are the correct ones for the current
v0.28.0
latest stable release.Please note:
_last_non_tagged_release_commit
has to be the first (earliest) new commit on main branch that is not reachable by going backwards from thev0.28.0
tag.You can find the correct commit to declare for pinning, by comparing the latest release tag of exiv2 with the main branch:
Or see GitHub compare:
v0.28.0...main
.The earliest-dated commit
37184fd
(fix print format) in the list is the right one to choose.(If you declared the main branch commit that is one commit earlier than the above, and therefore 'reachable' from going backwards from the
v0.28.0
tagged object, my linkedpkgver()
implementation would generate an improper version string:0.28.0~1
.)MarsSeed commented on 2023-06-30 12:59 (UTC)
Please kindly change the
pkgver()
to ensureRC
versions are not considered newer by pacman-based packaging tools than the following release version.Pacman follows basically the same version comparison logic as Python's packaging tools do (based on the PEP 440 standard).
You might wanna use an enhanced
pkgver()
implementation (like the one here).The linked example won't turn tags with e.g.
-RC2
to something like0.27.4.RC2.r*
, but instead join the text suffix directly to the version number (like0.27.4rc2.r*
).And filtering using
--match '[v0-9][0-9.][0-9.]*'
as in the linked code seems necessary, because at least in the past the project has pushed textual annotated tags, liketestIPO
.You can keep using
git describe --long
instead ofgit describe --long --tags
, because the project seems to use regular, annotated tags for release versions (as they should).(But I am seeing that the project does not always properly tag the
main
branch with release tags, therefore even though the latest release tag as of now is0.28.0
, the currently generated pkgver with my linked example implementation will show0.27.4rc2.r1839.g9215f740
. This is not something that we could reliably do about locally. It could and should be addressed by the project's developers in the future.)+1: If you implement my recommended
pkgver()
, you'll also need to bump toepoch=1
by adding this as a line in PKGBUILD, because the newly generated version string will already be considered older than the existing one with the.RC2
part.