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

[Peter Mattern]

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:
>
>> Hello.
>>
>> Considering the short time AUR 4 is in use the number of commits lacking
>> an update of .SRCINFO seems to be rather high.
>> The resulting problem is a cosmetic one only as the actual PKGBUILD
>> functionality isn't affected but only the package's web page not updated
>> accordingly.
>> 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.

>
>> Actually I wonder as well whether it wouldn't even be better to not have
>> .SRCINFO written by the packagers before uploading a commit but by
>> aurweb when commits are received.
>> This would ensure that problems like the one stated above can't happen
>> and I for one couldn't figure a downside so far.
> The downside is that running random bash scripts (PKGBUILDs) on the server is an
> unacceptable security risk. That's the entire reason these metadata files were
> created.

Admittedly I didn't consider PKGBUILD's nature as a shell script when 
submitting my first post. Given the structure of PKGBUILD I wonder 
whether writing .SRCINFO at the server side shouldn't be doable in a way 
avoiding security issues nevertheless.
Could of course very well be a task that isn't worth the pain.