[pacman-dev] [PATCH] makepkg: Treat pkgrel more similarly to pkgver
From: Luke Shumaker <lukeshu@parabola.nu> This is perfectly fine with libalpm; it was only makepkg that was more strict with pkgrel than pkgver. Further, the former error message about invalid pkgrel formats claimed that pkgrel was a "decimal", which would mean that `1.1 == 1.10`. This is not the case; alpm parses pkgrel as a version, not as a decimal. Signed-off-by: Luke Shumaker <lukeshu@parabola.nu> --- This is a patch from Parabola, that we've been maintaining and applying to our pacman package for a while. I originally wrote it against version 4.1.2, and have submitted upstream before: https://lists.archlinux.org/pipermail/pacman-dev/2014-August/019340.html Dan McGee and Allan McRae weren't fans of it then. https://lists.archlinux.org/pipermail/pacman-dev/2014-August/019340.html https://lists.archlinux.org/pipermail/pacman-dev/2014-September/019351.html Allan was "of the opinion that the pkgrel should be a positive integer and nothing else." Dan thought it shouldn't be complicated, as "we're not trying to copy or match an upstream value." Well, in Arch, you're not trying to copy an upstream value, but in Parabola and in Arch Linux 32, we are. Currently in Arch Linux 32 they take advantage of makepkg's current behavior: when modifying a PKGBUILD from Arch, they append ".$N to the pkgrel from Arch, and don't modify the existing number, so that it is easy to tell that "foo-X-Y.Z" is based on "foo-X-Y" from Arch (and Z is the Arch 32-specific pkgrel); they are matching an upstream value. Prior to applying this patch, Parabola did the same thing. Since applying this patch, we've transitioned to "foo-X-Y.parabolaZ". This is even more relevant now, since we also import packages from Arch 32, which may already have a ".Z". When building foo-static, we might use "foo-static-X-Y.staticZ" to clearly indicate that it is based on the PKGBUILD for "foo-X-Y". Allan had said that he would consider "Inclusion of a 'dist' keyword in PKGBUILDs. If present, this gets added onto the end of the pkgrel." I think that's introducing new weird semantics where we don't need any. Normal versioning semantics do fine; pkgrel is a version number of the packaging metadata, and "Y.distZ" says "version Y, and then Z patches", same as any other patchlevel; similar to ".gitZ" in a pkgver. doc/PKGBUILD.5.asciidoc | 3 ++- scripts/libmakepkg/lint_pkgbuild/pkgrel.sh.in | 4 ++-- test/util/vercmptest.sh | 23 ++++++++++++++++++- 3 files changed, 26 insertions(+), 4 deletions(-) diff --git a/doc/PKGBUILD.5.asciidoc b/doc/PKGBUILD.5.asciidoc index 9634bd15..a75b40fe 100644 --- a/doc/PKGBUILD.5.asciidoc +++ b/doc/PKGBUILD.5.asciidoc @@ -60,7 +60,8 @@ systems (see below). allows package maintainers to make updates to the package's configure flags, for example. This is typically set to '1' for each new upstream software release and incremented for intermediate PKGBUILD updates. The - variable is not allowed to contain hyphens. + variable is not allowed to contain colons, forward slashes, hyphens or + whitespace. *epoch*:: Used to force the package to be seen as newer than any previous versions diff --git a/scripts/libmakepkg/lint_pkgbuild/pkgrel.sh.in b/scripts/libmakepkg/lint_pkgbuild/pkgrel.sh.in index f294a3bf..07292613 100644 --- a/scripts/libmakepkg/lint_pkgbuild/pkgrel.sh.in +++ b/scripts/libmakepkg/lint_pkgbuild/pkgrel.sh.in @@ -35,8 +35,8 @@ lint_pkgrel() { return 1 fi - if [[ $pkgrel != +([0-9])?(.+([0-9])) ]]; then - error "$(gettext "%s must be a decimal, not %s.")" "pkgrel" "$pkgrel" + if [[ $pkgrel = *[[:space:]/:-]* ]]; then + error "$(gettext "%s is not allowed to contain colons, forward slashes, hyphens or whitespace.")" "pkgrel" "$pkgrel" return 1 fi } diff --git a/test/util/vercmptest.sh b/test/util/vercmptest.sh index 1541e7ae..f41a0d1e 100755 --- a/test/util/vercmptest.sh +++ b/test/util/vercmptest.sh @@ -39,7 +39,7 @@ tap_runtest() { tap_is_str "$($bin "$ver2" "$ver1")" "$exp" "$ver2 $ver1" } -tap_plan 92 +tap_plan 124 # all similar length, no pkgrel tap_runtest 1.5.0 1.5.0 0 @@ -113,4 +113,25 @@ tap_runtest 1:1.0 1.0 1 tap_runtest 1:1.0 1.1 1 tap_runtest 1:1.1 1.1 1 +# complex pkgrel values +tap_runtest 1-1.5.0 1-1.5.0 0 +tap_runtest 1-1.5.1 1-1.5.0 1 +tap_runtest 1-1.5.1 1-1.5 1 +tap_runtest 1-1.5b 1-1.5 -1 +tap_runtest 1-1.5b 1-1.5.1 -1 +# based on "from the manpage" +tap_runtest 1-1.0a 1-1.0alpha -1 +tap_runtest 1-1.0alpha 1-1.0b -1 +tap_runtest 1-1.0b 1-1.0beta -1 +tap_runtest 1-1.0beta 1-1.0rc -1 +tap_runtest 1-1.0rc 1-1.0 -1 +# based on "going crazy? alpha-dotted versions" +tap_runtest 1-1.5.a 1-1.5 1 +tap_runtest 1-1.5.b 1-1.5.a 1 +tap_runtest 1-1.5.1 1-1.5.b 1 +# based on Parabola usage +tap_runtest 1-1 1-2.par1 -1 +tap_runtest 1-2 1-2.par1 -1 +tap_runtest 1-3 1-2.par1 1 + tap_finish -- 2.17.1
On 04/06/18 06:01, Luke Shumaker wrote:
From: Luke Shumaker <lukeshu@parabola.nu>
This is perfectly fine with libalpm; it was only makepkg that was more strict with pkgrel than pkgver.
Further, the former error message about invalid pkgrel formats claimed that pkgrel was a "decimal", which would mean that `1.1 == 1.10`. This is not the case; alpm parses pkgrel as a version, not as a decimal.
Signed-off-by: Luke Shumaker <lukeshu@parabola.nu> ---
I am still very much against going beyond x.y for pkgrel. In fact, I only begrudgingly accept the need for .y in there. A
participants (2)
-
Allan McRae
-
Luke Shumaker