Am 26.07.2015 um 20:58 schrieb Doug Newgard:
On Sun, 26 Jul 2015 17:09:49 +0200 Peter Mattern <pmattern@arcor.de> wrote:
On Sun, 26 Jul 2015 14:48:04 +0200 Peter Mattern<pmattern@arcor.de> wrote:
Yet I wonder whether it would be helpful to reject commits lacking the update of .SRCINFO if feasible. Please don't. What about commits that make changes to the PKGBUILD but require no changes to .SRCINFO? But how should such a change to PKGBUILD look like? IMO each reasonable change to PKGBUILD involves bumping pkgver and/or
Am 26.07.2015 um 16:00 schrieb Doug Newgard: pkgrel and as such makes adjusting .SRCINFO mandatory, no? And even if changes like this do exist I can hardly figure they outweigh the disadvantages stated by Remy in the meantime. There are plenty of changes that could be made to the PKGBUILD that wouldn't require a change to the .SRCINFO. Anything from formatting changes/cleanups, to restructuring functions, to switching to using install commands instead of cp, to abstracting out variables. You don't want to bump the pkgrel if they don't make any changes to the final package.
What exactly is the benefit of an isolated upload of a PKGBUILD that doesn't change the package itself at all, in particular now that Git is used and everybody has got a local checkout at hand anyway? If there should be any benefit at all it for sure doesn't outweigh disadvantages like outdated package sites or RPC issues affecting AUR helpers. And as soon as a modification of PKGBUILD does change the package at least a release bump is justified and thus an update of .SRCINFO as well.