On Sun, 26 Jul 2015 14:48:04 +0200 Peter Mattern<pmattern@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
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.
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.