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