Hi Georg, thank you for your reply. If I am understanding correctly, pkgrel is for changes to the PKGBUILD, and pkgver is for changes to the actual sources. Is this correct? Yash On 3/3/20, Georg wrote:

Hi Yash, and welcome to archlinux. pkgrel is the internal revision of the package, e.g. the packaging version. This allows improvements on the package without bumping the software release version and is often used for binary rebuild to adapt to changed dependencies etc. Georg

Awesome, thanks! On Tue, Mar 3, 2020 at 1:40 PM Bert Peters wrote:

On Tue, 2020-03-03 at 13:29 -0600, karx via aur-general wrote:

...

Hi Georg, thank you for your reply. If I am understanding correctly, pkgrel is for changes to the PKGBUILD, and pkgver is for changes to the actual sources. Is this correct?

Yash

Correct. Although the PKGBUILD doesn't have to have significant changes; it can just be that other packages changed instead. You can look at the history of the shellcheck PKGBUILD [1] to get an idea.

Bert.

[1]: https://git.archlinux.org/svntogit/community.git/log/trunk?h=packages/shellc...

On Tue, 3 Mar 2020 13:29:30 -0600 karx via aur-general wrote:

Hi Georg, thank you for your reply. If I am understanding correctly, pkgrel is for changes to the PKGBUILD, and pkgver is for changes to the actual sources. Is this correct?

Yash

On 3/3/20, Georg wrote:

...

Hi Yash, and welcome to archlinux. pkgrel is the internal revision of the package, e.g. the packaging version. This allows improvements on the package without bumping the software release version and is often used for binary rebuild to adapt to changed dependencies etc. Georg

Kind of. pkgrel is for changes to the built package, there's plenty of changes you can make to the PKGBUILD that don't change the actual package; those don't require a pkgrel change.

On 3/3/20 6:28 PM, karx via aur-general wrote:

On Tue, Mar 3, 2020, 5:23 PM Doug Newgard via aur-general < aur-general@archlinux.org> wrote:

...

On Tue, 3 Mar 2020 13:29:30 -0600 karx via aur-general wrote:

...

Hi Georg, thank you for your reply. If I am understanding correctly, pkgrel is for changes to the PKGBUILD, and pkgver is for changes to the actual sources. Is this correct?

Yash

On 3/3/20, Georg wrote:

...

Hi Yash, and welcome to archlinux. pkgrel is the internal revision of the package, e.g. the packaging version. This allows improvements on the package without bumping the software release version and is often used for binary rebuild to adapt to changed dependencies etc. Georg

Kind of. pkgrel is for changes to the built package, there's plenty of changes you can make to the PKGBUILD that don't change the actual package; those don't require a pkgrel change.

Like what?

Whitespace or quoting changes. Switching from "mkdir -p foo && cp foo bar/baz" to "install -Dm644 foo bar/baz". Changing the CMake generator between GNU Makefiles and Ninja. -- Eli Schwartz Bug Wrangler and Trusted User

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