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

[Doug Newgard]

On Tue, 28 Jul 2015 16:52:35 +0200
Peter Mattern <pmattern at 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 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.

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?