[aur-general] What is pkgrel and why/how should I use it?

[Eli Schwartz]

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.
>>>
>>> Thanks, Yash
>>
>> 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?)

-- 
Eli Schwartz
Bug Wrangler and Trusted User

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1601 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20200303/27896090/attachment.sig>