[pacman-dev] [RFC] Package parser in python

[Allan McRae]

Xavier wrote:
> I can't help but think this whole situation is stupid.
> 
> I would suppose that PKGBUILDs were written in bash for simplicity
> reason : makepkg just needs to source them, and that's it. Whole
> parsing done for free.
> And now we realize that when using untrusted source, we cannot do that
> anymore. And now we basically have to rewrite a bash parser from
> scratch. I mean, it's hard to imagine a more flawed design, and more
> complex solution to a simple problem.
> 
> Somehow we manage to go from a very KISS solution to a completely anti-KISS one.

I think it is still a KISS solution for _building packages_.  That is 
what PKGBUILDs and makepkg are supposed to do.  Anything other than 
building packages that is to be done with PKGBUILDs is secondary.

> I only see two solutions :
> - we keep using bash, but try to do that in the most restricted
> environment possible (e.g. namcap way , or maybe there is something
> even more restrictive and secure ?)

It is not particularly possible given all the bash "tricks" used in 
PKGBUILDs.

> - we decide that pkgbuild format is a flawed design, and was too
> limited for our needs, and switch to a new one (in which case Xyne's
> brainstorming could help : http://xyne.archlinux.ca/ideas/pkgmeta )

As I said above, I do not believe it is flawed. The PKGBUILD format 
specifies how to create a package in a simple way that is interpreted by 
makepkg while still maintaining all the flexibility of bash (and all 
software is built from the shell...).  It does its job well.

I know people (including me) have encountered the need to parse 
PKGBUILDs for purposes other that building packages (AUR2, repo checking 
scripts, makepkg test suite...), but I have yet to see a suggestion that 
can handle all the complexities available to the current PKGBUILD format 
while retaining its simplicity.

Allan