The api function get_pkgver_and_pkgrel did not correctly parse pkgver when its defintion uses shell parameter expansion. For example, in R package PKGBUILDs it's common to define pkgver like this.
_pkgver=1.2-3
pkgver=${_pkgver//[:-]/.}
The old implementation would parse the pkgver as literal ${_pkgver//[:-]/.} instead of the correct 1.2.3. This is a problem, because get_pkgver_and_pkgrel is used in worker.may_update_pkgrel context manager, which is used in worker.lilac_build to check if the pre_build script has updated pkgver.
In the case of R packages, a custom pre_build script updates the _pkgver variable, but the pkgver variable is left as it is, since the parameter expansion will set its value based on the _pkgver variable. The get_pkgver_and_pkgrel wouldn't know this, which made worker.may_update_pkgrel to increase the value of pkgrel even when the package version was updated.
This build log of r-jsonlite shows the problem. The package is updated from 1.8.4 to 1.8.5, so the pkgrel should be reset to 1 (it was originally 4), and the pre_build script indeed does this, as seen from the output of the makepkg -od --noprepare -A command.
==> Making package: r-jsonlite 1.8.5-1 (Mon 05 Jun 2023 06:01:40 PM GMT)
However, when the may_update_pkgrel context manager finishes, it thinks that the pkgver hasn't changed, so it increments the pkgrel.
[I 06-05 18:01:41.019 api:251] pkgrel updated to 5
And the final package version ends up being 1.8.5-5 instead of 1.8.5-1.
This pr makes get_pkgver_and_pkgrel to use the result of the parameter expansion by sourcing the PKGBUILD and printing the values of the variables. Another possible solution would be to disable automatic pkgrel incrementing if the pkgver contains a $ character.
The api function
get_pkgver_and_pkgreldid not correctly parsepkgverwhen its defintion uses shell parameter expansion. For example, in R package PKGBUILDs it's common to definepkgverlike this.The old implementation would parse the
pkgveras literal${_pkgver//[:-]/.}instead of the correct1.2.3. This is a problem, becauseget_pkgver_and_pkgrelis used in worker.may_update_pkgrel context manager, which is used in worker.lilac_build to check if thepre_buildscript has updatedpkgver.In the case of R packages, a custom
pre_buildscript updates the_pkgvervariable, but thepkgvervariable is left as it is, since the parameter expansion will set its value based on the_pkgvervariable. Theget_pkgver_and_pkgrelwouldn't know this, which madeworker.may_update_pkgrelto increase the value ofpkgreleven when the package version was updated.This build log of
r-jsonliteshows the problem. The package is updated from1.8.4to1.8.5, so thepkgrelshould be reset to 1 (it was originally 4), and thepre_buildscript indeed does this, as seen from the output of themakepkg -od --noprepare -Acommand.However, when the
may_update_pkgrelcontext manager finishes, it thinks that thepkgverhasn't changed, so it increments thepkgrel.And the final package version ends up being
1.8.5-5instead of1.8.5-1.This pr makes
get_pkgver_and_pkgrelto use the result of the parameter expansion by sourcing the PKGBUILD and printing the values of the variables. Another possible solution would be to disable automaticpkgrelincrementing if thepkgvercontains a$character.