Hi bitswitcher, thanks for the updates.
Your PKGBUILD is now perfectly fine as is. The entire version is always incorporated. You’re right in that some of the examples in the wiki happen to have just major and minor versions. However, if you look at the combined example, you’ll see it shows the patch version, too.
Generally, the git describe part always picks up the full tag name, no matter how deeply nested its name is, including patch-level numbers or even deeper. So we’re all clear now!
Hey Auerhuhn,
Thank you for the feedback and thank you for linking directly to the Arch Wiki. I believe I have made the appropriate changes. I went ahead and did a 1.0.0 release for my project. Given that I've included a patch version in my git tag, does that create a problem for my AUR version? It seems that the examples in the wiki only show a major and minor version in the tags, but not a patch version.
Hi bitswitcher,
Thanks for contributing to the AUR. Your PKGBUILD looks clean and neat.
Would you mind addressing the following remaining issues?
-
The PKGBUILD fails to build in a clean chroot because it doesn’t have git in its makedepends. Would you mind adding the dependency?
-
A VCS package needs some way to auto-bump the pkgver. Without an auto-bump, users aren’t going to get updates unless the PKGBUILD itself is updated.
Please choose one of the Git auto-bump methods in our VCS package guidelines and add them to your PKGBUILD.
Given that the upstream repository doesn’t have any tags (yet), I’d recommend that you use this one:
pkgver() {
cd "$pkgname"
( set -o pipefail
git describe --long --abbrev=7 2>/dev/null | sed 's/\([^-]*-g\)/r\1/;s/-/./g' ||
printf "r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short=7 HEAD)"
)
}
Alternatively, feel free to use the simpler one that just does printf "r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short=7 HEAD)".
Thanks!
Regards
Claudia (aka Auerhuhn)