On Sat, Dec 12, 2009 at 5:30 PM, Allan McRae <allan@archlinux.org> wrote:
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.
You are right, but I still consider it a design flaw when the secondary usages were not considered :)
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.
Why is that ? Things like calling external commands and such ? And would the alternative parser support these bash tricks anyway ? So why don't we just forbid / not support them ? At least that sounds less overkill than a new format :) To workaround the problem of sourcing untrusted code, I was also thinking : maybe there could be a system (AUR alternative) where there is no untrusted code ? Like pkgbuilds could be uploaded, but not parsed and showed in the interface until they are human approved (either by a trusted user, or by a community approval system, whatever). Anyway, I am going very far here. Feel free to ignore these stupid ideas and concentrate on the previous more pragmatic (and maybe also stupid) ideas.
- 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.
It's not only hard, but I am not even sure what we would do if we had one. Sounds like an alternative format would almost justify a new distribution. Otherwise we have to handle backward compatibility, and probably conversion between the two. And it would still be confusing :)