Am 26.07.2015 um 16:00 schrieb Doug Newgard:
On Sun, 26 Jul 2015 14:48:04 +0200
Peter Mattern<[email protected]> 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.
