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

[Xavier]

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
> 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
:)