On Sat, Dec 12, 2009 at 5:30 PM, Allan McRae <[email protected]> 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 :)
