[pacman-dev] [RFC] Package parser in python
allan at archlinux.org
Sat Dec 12 11:30:58 EST 2009
> 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
> - 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.
More information about the pacman-dev