[pacman-dev] [RFC] Package parser in python

Xavier shiningxc at gmail.com
Sat Dec 12 20:10:20 EST 2009

On Sat, Dec 12, 2009 at 5:30 PM, Allan McRae <allan at 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

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

More information about the pacman-dev mailing list