On 3/3/20 3:50 PM, Alexander Fasching wrote:
On Tue, 2020-03-03 at 15:36 -0500, Eli Schwartz via aur-general wrote:
On 3/3/20 2:09 PM, karx via aur-general wrote:
Hello all, sorry if this is not in the appropriate mailing list. I am developing an AUR package, and it says that pkgrel is a required field. Right now, I simply leave it at 1, but I want to know how I should really use it and what its purpose is.
This mailing list is fine for any discussion about developing AUR packages, including questions about the PKGBUILD format.
But I am curious -- have you read the wiki documentation at https://wiki.archlinux.org/index.php/PKGBUILD#pkgrel and if so, is there anything that was still unclear to you after reading it?
I have a question about pkgrel and git commits in the AUR. Should I update pkgrel every time I make a commit and don't change pkgver? I use aurpublish to manage my packages and I have some commits that don't change pkgrel because I don't publish these commits.
I don't see a problem doing it this way because people who build from intermediate commits should know what they are doing, but I don't know if there are any guidelines on it. If pkgrel should be updated, then maybe the aurpublish hooks should enforce this.
The pkgver and pkgrel together (and epoch, if it exists), together form, let's call it the "fullpkgver". For example, pacman is 5.2.1-4 and zlib is 1:1.2.11-4
Every time the built package changes, whether that is due to building different code, or having different packaging metadata (new dependencies, etc.) the fullpkgver *must* change.
If the change is due to a new version of the code being built, then the pkgver= field changes (and pkgrel is reset).
If the change is due to the PKGBUILD enabling different options, or adding new dependencies, or similar, then the pkgver naturally cannot change, so instead we increment the packaging-specific version suffix, i.e. the pkgrel. Ultimately, the package can still be uniquely identified via its fullpkgver and shows up as a new (upgradeable) package.
If all you did was modify the formatting or something, then obviously this does not qualify for a pkgrel bump.
I think, though, that you are asking about changes which *do* modify the package, but which were never publicly pushed (and were used for local testing, I suppose). I don't see anything particularly wrong with only incrementing the pkgrel once in this case, though personally I tend to use git commit --amend and then push one new commit in such cases.
Since users never end up with a changed package but without an updated pkgrel, it never affects them and does not matter. Think of it like a transitional state between two tags, or a patch series merged using the "git merge --no-ff" option.
So I would not worry about updating the pkgrel in such cases. (I guess if you really want to, you could?)