Excerpts from Jeremy Audet via aur-general's message of November 5, 2019 7:51 pm: >> > What if regular, non development, AUR packages were tested server side >> > for new versions? >> > Won't that make more sense than the maintainer having to run pkgver() >> > manually from time to time? >> >> We shall not evaluate user-uploaded shellscripts on the AUR server. Most >> AUR helpers provide a --devel option to download packages with a >> pkgver() function and check them for updates. >> >> Non-development AUR packages are not permitted to change their version >> just by running makepkg and having the pkgver() update it, since this >> implies that the non-development AUR package uses VCS sources that are >> not pinned to a specific commit or tag. >> >> Please report such package violations for deletion or other corrective >> measures. > > To expand on Eli's answer: executing arbitrary shell scripts is dangerous. It > might be possible to constrain the damage that could be inflicted through > aggressive use of sandboxing mechanisms (e.g. standing up a container with > systemd-nspawn and locking it down with directives like PrivateNetwork=true), > but this would break pkgver() for VCS packages, and this is also just begging > for trouble. I believe the .SRCINFO file was added so that the AUR could > discover a PKGBUILD's version without needing to evaluate arbitrary scripts. > As far as I know the AUR did not, at any point, evaluate arbitrary scripts to retrieve metadata. It did parse (or attempt to...) the PKGBUILD.
See also: <https://wiki.archlinux.org/index.php/.SRCINFO> Alad
pgpLPLcLFI0Go.pgp
Description: PGP signature
