[aur-dev] AUR2

[Laszlo Papp]

> Boys,
>
> I've been chatting with Laszlo for a bit. It's very refreshing to see some
> enthusiasm on the subject of AUR2 again. I've been working on the Lex/Yacc
> parser for the PKGBUILD but it hasn't been touched since May because of a
> number of reasons, but this thread has helped spark my interest again.
> Before we start doing some serious coding though, we really need to take a
> step back and go back to the drawing board.
>
> >From reading this thread, we can break down what we want to accomplish
> into
> 3 separate components:
>
> Client - (Web/CLI Frontend)
> Data - (PKGBUILD)
> Server - (Repository)
>
> Obviously each component will have its own sub-modules. Let's not get these
> core components mixed up though. We first need to completely nail the
> specifications of the data and the structure of a source-package
> (non-binary). That means comments on Loui's RFC and overall brainstorming
> of
> what consists of a source-package. My comments on the RFC and metadata
> structuring:
>
> 1) I like the direction of the proposed PKGINFO. I don't know if the
> pkgbase/pkgname mechanism is the right answer, but making dependencies an
> attribute of the architecture makes a lot of sense.
>
>
We talked about it with Louipc, Sebastian yesterday so much. Your
yacc/lex/bison implementation is worth to give a try I think so.
Short summary of the yesterday talking on #archlinux-aur, just for our fresh
informations (please fix me, if I'm wrong with it):

1) PKGINFO can contain duplicated and unneccesary data and it's support only
for AUR project at this momment (however it would be good if ABS would be
refactored), so this is hard to be accepted by pacman developers to
establish it.
2) Current PKGBUILD parsing is hard from C, easier from bash and python but
not so easy with CARCH related parts of it.
3) Give a try with yacc/lex/bison handling, it would be just building
dependency, not runtime.

I dealt with the server and frontend part of this project recently,  but not
so much with json-api interface establishing between the server and the
frontend. It's important to establish a good server program and API for
frontends to be able to handle it easily.
I will commit some server related codes soon into the aurman project, any
feedback will be welcomed :) But it will be needed to rewrite as the AUR
database will be changed (I hope it will be changed.), but it will be
extension than a totally rewritten database in my opinion, but anything can
occur.

I think it's needed to change the database schema too, because it has got
some lack of informations now. (e.g. registration date of a user, etc.)

2) Why aren't we using a markup language like XML or JSON?  It would make
> parsing really easy, and making clients would be a lot easier. As for the
> build() function... can't we just use Makefiles? That's essentially what it
> is. There was actually a thread on the forums about this.
>
>
As I told in this thread earlier, I support JSON interface, because it's
well supported in scripting/programming languages and relatively easy to
handle, so it could be a good unity in this project. I don't think Makefiles
would be an easy task for pacman developer to accept it.


> 3) Right now there's a redundancy in how package metadata is treated. If
> you
> look at /var/lib/pacman (which deals with binary packages), it splits up
> the
> metadata in depends/desc/files/install, etc. If you look at the ABS (deals
> with source packages), it splits up the metadata in PKGBUILDs and PKGINFOs.
> Why not just use one or the other?
>
> More on this topic later. Cheers.
>
> --
> Ryan Coyner [http://ryancoyner.com]
>

It's a duplicated question maybe :P If you can establish your yacc/lex
'interface', PKGBUILD can be more than enough for this problem even if it's
not so easy to parse it.



Best Regards,
Laszlo Papp