[aur-general] Updating AUR versions server side
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? (Reply including me on the recipients) Alberto https://es20490446e.wordpress.com
On 11/3/19 12:39 PM, Alberto Salvia Novella via aur-general wrote:
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. -- Eli Schwartz Bug Wrangler and Trusted User
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.
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
[...] 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
You're right. I should've spent a minute reading the Arch Wiki page on .SRCINFO files before writing that, instead of working from memory.
participants (4)
-
Alad Wenter
-
Alberto Salvia Novella
-
Eli Schwartz
-
Jeremy Audet