You are not logged in.
I understand that pkgrel should be incremented if changes are made to a PKGBUILD, which result in the same package version being built. I also see that when version of the package changes, that pkgrel should be reset to 1: https://wiki.archlinux.org/index.php/PKGBUILD#pkgrel
The guidance for VCS packages amends this advice: https://wiki.archlinux.org/index.php/VC … guidelines. It says that similar to regular PKGBUILDs that pkgrel should increase with PKGBUILD changes, but is not explicit that it's reset for new VCS versions (which makes sense with a pkgver() function). Does this mean that pkgrel for VCS builds will always go up, or is makepkg clever enough to reset pkgrel if the version changes?
I'm asking this as I have forked a few AUR PKGBUILDs and am wondering if I should also update their pkgrel, and if so, what to do if the upstream PKBUILD also increases theirs.
Bonus questions: are there VCS packages in the ABS? I couldn't find any relevant -git or -svn packages. Is that mandated or just a strong enough preference for none to exist?
Last edited by sshaikh (2020-11-30 18:09:50)
Offline
makepkg resets it
on the bonus, it's about distributing binary packages, you need the PKGBUILD to build the same thing.
Offline
I understand that pkgrel should be incremented if changes are made to a PKGBUILD, which result in the same package version being built. I also see that when version of the package changes, that pkgrel should be reset to 1: https://wiki.archlinux.org/index.php/PKGBUILD#pkgrel
The guidance for VCS packages amends this advice: https://wiki.archlinux.org/index.php/VC … guidelines. It says that similar to regular PKGBUILDs that pkgrel should increase with PKGBUILD changes, but is not explicit that it's reset for new VCS versions (which makes sense with a pkgver() function). Does this mean that pkgrel for VCS builds will always go up, or is makepkg clever enough to reset pkgrel if the version changes?
I'm asking this as I have forked a few AUR PKGBUILDs and am wondering if I should also update their pkgrel, and if so, what to do if the upstream PKBUILD also increases theirs.
"Try it and see".
Anyway if you have pkgver=r11 and pkgrel=4 (so r11-4), but then people build updated code and get pkgver=r12 (so r12-1 or r12-4 depending on whether makepkg "is clever enough"), then bumping the PKGBUILD to pkgver=r11 and pkgrel=5 (so r11-5) won't show up as newer than the version people installed, no matter which it is. You must run makepkg to get the updated VCS version (r12), and at that point either the pkgrel is cleverly reset for you, so you should bump it from "1" to "2", or it is not reset for you, and you should bump it from "4" to "5". Either way you are bumping it.
Bonus questions: are there VCS packages in the ABS? I couldn't find any relevant -git or -svn packages. Is that mandated or just a strong enough preference for none to exist?
Strictly forbidden, as Scimmia said.
Plus we are bleeding edge, "latest release is awesome", which is distinctively different from packaging completely unreleased WIP code, so we generally don't do that without either:
- strong reasons, or
- the gnome ecosystem (apparently)
If we do, it's mandatory to use pinned commits in the PKGBUILD.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
It says that similar to regular PKGBUILDs that pkgrel should increase with PKGBUILD changes, but is not explicit that it's reset for new VCS versions (which makes sense with a pkgver() function).
If you make any changes in the PKGBUILD, but there have not been any upstream changes since you last pushed the PKGBUILD to the aur, then you should increment pkgrel. If there have been upstream changes, then the pkgver should increase, and pkgrel can be reset to 1. The requirement is only to keep a monotonically increasing value of pkgver-pkgrel; if there is a change in pkgver, pkgrel can be reset. This is no different in VCS PKGBUILDs than non-VCS, so it doesn't need special mention.
Last edited by Trilby (2020-11-30 20:01:50)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Anyway if you have pkgver=r11 and pkgrel=4 (so r11-4), but then people build updated code and get pkgver=r12 (so r12-1 or r12-4 depending on whether makepkg "is clever enough"), then bumping the PKGBUILD to pkgver=r11 and pkgrel=5 (so r11-5) won't show up as newer than the version people installed, no matter which it is. You must run makepkg to get the updated VCS version (r12), and at that point either the pkgrel is cleverly reset for you, so you should bump it from "1" to "2", or it is not reset for you, and you should bump it from "4" to "5". Either way you are bumping it.
When I fork/hack/improve an existing PKGBUILD, my intention was to rename the package and populate the conflicts and provides (as per https://bbs.archlinux.org/viewtopic.php?id=95296). I was wondering how that should reflect when the upstream PKGBUILD changes, but now I realise that since the package is new and my own, so is the pkgrel.
So I think I was actually conflating two questions ("what to do with pkgrel when forking PKGBUILDs" and "does makepkg automatically reset a VCS PKGBUILD's pkrel or do you have to"). But I get it now (I think).
Offline
When you fork a PKGBUILD and change the pkgname, it occupies a different namespace and its own completely new pkgrel tracking.
The only question tying back to the original package becomes "should I provides=('foo=r11-4') or just provides=('foo=r11') or not bother with versions and just provides=('foo') and be content with that".
It's not really relevant to provide a specific pkgrel under any circumstances I can think of.
Last edited by eschwartz (2020-11-30 20:16:38)
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline