On Mon, Sep 16, 2013 at 04:59:03PM +0000, Xyne wrote:
Dave Reisner wrote:
And you'd need to do all this work at a level lower than the parser itself to avoid subversion via aliases, functions, and scripts which mask the actual operation's nature...
I think I've mentioned this a few times, but I think there's 2 options if you want better parsing on the AUR:
1) Extend .AURINFO, implement it as .SRCINFO in makepkg proper. To date, I think there's been a number of issues which no one has been willing to address to make this a reality.
Wouldn't that need to actually build everything to access the data nested in the package functions? That wouldn't necessarily be a bad thing as it would require packages to check that the package builds, but in that case you may as well just extract the data from .PKGINFO.
Feel free to write a script that creates .AURINFO from .PKGINFO.
2) Use a VM (e.g. http://www.vidarholen.net/contents/evalbot/) to evalulate the code. This would require something very similar to the guts of makepkg which understands per-package overrides. The output would be something similar to #1, so really... interested parties should just work on that.
I honestly think the best approach would be to replace Bash PKGBUILDs with a versatile metadata language that can be easily and safely parsed, e.g. JSON with support for variables and maybe a limited set of custom macros. Build and package functions could be moved to external scriptlets, e.g. '{"build" : "/path/to/build.sh", ...}'.
Yet another item on my todo list. :P
If you combine .AURINFO and PKGBUILD you already have a format that provides pretty much everything you want.
You'd probably be interested in shellcheck:
It's written in Haskell, and while it doesn't execute anything, it does understand a large amount of bash syntax. I found an obscure bug in it recently which was quickly fixed by the author (he's a denizen of #bash on freenode).
That is indeed interesting.