Message ID | 20180809174237.29607-1-lukeshu@lukeshu.com |
---|---|
State | Accepted, archived |
Headers | show |
On 10/8/18 3:42 am, Luke Shumaker wrote: > From: Luke Shumaker <lukeshu@parabola.nu> > > lint_pkgver returns 0 if PKGVERFUNC, since it's likely that update_pkgver() > will change the value of pkgver anyway, and there's no point in linting the > old value. update_pkgver() will call check_pkgver() itself to validate the > new value. > > However, that "optimization" only holds if we're definitely going to call > update_pkgver() later; and that's way more complicated than > > if (( PKGVERFUNC )); then > > it's more like: > > if (( !GENINTEG && !PACKAGELIST && !PRINTSRCINFO && !SOURCEONLY && !REPKG && PKGVERFUNC )); then > > Which is to say: If I have a PKGBUILD with pkgver(): > > * if I run `makepkg -g` I expect it to lint pkgver, but it won't > * if I run `makepkg -R` I expect it to lint pkgver, but it won't > * ... > > So let's fix that. > > Rather than try to keep a huge list of conditions in sync with the flow of > makepkg.sh.in, let's just drop it. As far as I can tell, the only thing > that skipping lint_pkgver() really enables is letting the PKGBUILD author > write `pkgver=` in the initial version, and letting pkgver() fill it in. > They can just start writing `pkgver=0` for that workflow. > --- Massive commit message for a -5 patch! You have me convinced. Also, it is great to see an @parabola email address contributing. > scripts/libmakepkg/lint_pkgbuild/pkgver.sh.in | 5 ----- > 1 file changed, 5 deletions(-) > > diff --git a/scripts/libmakepkg/lint_pkgbuild/pkgver.sh.in b/scripts/libmakepkg/lint_pkgbuild/pkgver.sh.in > index 65216b64..e9b1566f 100644 > --- a/scripts/libmakepkg/lint_pkgbuild/pkgver.sh.in > +++ b/scripts/libmakepkg/lint_pkgbuild/pkgver.sh.in > @@ -44,10 +44,5 @@ check_pkgver() { > } > > lint_pkgver() { > - if (( PKGVERFUNC )); then > - # defer check to after getting version from pkgver function > - return 0 > - fi > - > check_pkgver "$pkgver" > } >
On 9/19/18 4:02 AM, Allan McRae wrote: > Massive commit message for a -5 patch! You have me convinced. > > Also, it is great to see an @parabola email address contributing. Speaking as a fellow writer of manuscript-style commit messages, ditto and ditto. :D
diff --git a/scripts/libmakepkg/lint_pkgbuild/pkgver.sh.in b/scripts/libmakepkg/lint_pkgbuild/pkgver.sh.in index 65216b64..e9b1566f 100644 --- a/scripts/libmakepkg/lint_pkgbuild/pkgver.sh.in +++ b/scripts/libmakepkg/lint_pkgbuild/pkgver.sh.in @@ -44,10 +44,5 @@ check_pkgver() { } lint_pkgver() { - if (( PKGVERFUNC )); then - # defer check to after getting version from pkgver function - return 0 - fi - check_pkgver "$pkgver" }
From: Luke Shumaker <lukeshu@parabola.nu> lint_pkgver returns 0 if PKGVERFUNC, since it's likely that update_pkgver() will change the value of pkgver anyway, and there's no point in linting the old value. update_pkgver() will call check_pkgver() itself to validate the new value. However, that "optimization" only holds if we're definitely going to call update_pkgver() later; and that's way more complicated than if (( PKGVERFUNC )); then it's more like: if (( !GENINTEG && !PACKAGELIST && !PRINTSRCINFO && !SOURCEONLY && !REPKG && PKGVERFUNC )); then Which is to say: If I have a PKGBUILD with pkgver(): * if I run `makepkg -g` I expect it to lint pkgver, but it won't * if I run `makepkg -R` I expect it to lint pkgver, but it won't * ... So let's fix that. Rather than try to keep a huge list of conditions in sync with the flow of makepkg.sh.in, let's just drop it. As far as I can tell, the only thing that skipping lint_pkgver() really enables is letting the PKGBUILD author write `pkgver=` in the initial version, and letting pkgver() fill it in. They can just start writing `pkgver=0` for that workflow. --- scripts/libmakepkg/lint_pkgbuild/pkgver.sh.in | 5 ----- 1 file changed, 5 deletions(-)