Package Details: exiv2-git 0.27.4.RC2.r247.gc7a41230f-2

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)

Required by (90)

Sources (1)

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 branch CMakeLists.txt file's project version to a bogus 1.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:

provides=("exiv2=$pkgver" 'libexiv2.so')

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:

_last_non_tagged_release_ver=0.28.0    # declare without 'v' prefix even if the git tag has such
_last_non_tagged_release_commit=37184fd71330064a3e6f508110f998a69b3db37b

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 the v0.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:

$ git fetch --tags --prune # (only needed if your git is not already configured to use those options by default)
$ git log -n 1 --format=oneline --reverse --right-only v0.28.0...main

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 linked pkgver() 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 ensure RC 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 like 0.27.4.RC2.r*, but instead join the text suffix directly to the version number (like 0.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, like testIPO.

You can keep using git describe --long instead of git 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 is 0.28.0, the currently generated pkgver with my linked example implementation will show 0.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 to epoch=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.