[aur-general] Merge request: python2-pyside -> python-pyside

[Jerome Leclanche]

On Mon, Sep 16, 2013 at 5:59 PM, Xyne <xyne at archlinux.ca> 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.
>
>>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

That makes pkgbuilds needlessly complex to write; json is not exactly
a good fit to be human-written (no comments, no trailing commas, ...).
makepkg / makepkg -S does run through the bash script, it can gather
all the metadata at that point and autogenerate such a json file.

>
>
>
>>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.