On Tue, 28 Jul 2015 16:52:35 +0200 Peter Mattern <pmattern@arcor.de> wrote:
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.
All commits are checked, not just HEAD when you push. Adding this check would make it so you cannot have commits like this at all, even if you only push later when there is another change. And how about something as simple as changing the maintainer tag?