[aur-dev] .SRCINFO: handling of commits lacking an update and in general

[Peter Mattern]

Am 26.07.2015 um 20:58 schrieb Doug Newgard:
> On Sun, 26 Jul 2015 17:09:49 +0200
> Peter Mattern <pmattern at arcor.de> wrote:
>> Am 26.07.2015 um 16:00 schrieb Doug Newgard:
>>> On Sun, 26 Jul 2015 14:48:04 +0200
>>> Peter Mattern<pmattern at 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
>> 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.