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
