[aur-dev] .SRCINFO: handling of commits lacking an update and in general
scimmia at archlinux.info
Sun Jul 26 18:58:35 UTC 2015
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.
> >> 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.
That's what we had before. It only works in very simple cases. Remember,
anything that's valid in bash is valid in a PKGBUILD.
More information about the aur-dev