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: > > > >http://www.shellcheck.net/ > > > >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.
