[aur-dev] AUR2 Direction
Hi guys, I've picked up AUR2 development once again, and made it work with Django 1.0+. I want to start working on binary package support, but I'm unsure as to how to go about it. The current AUR depends on background scripts which populate the database. I really don't like this idea. It's fine for them to exist, but AUR2 should not depend on them. I was thinking of writing a parser for binary packages[1] and using the same upload interface for binary packages as for PKGBUILD packages. Permissions to upload would obviously be restricted to specific groups. This generalization would also allow me to get get rid of some hard coded logic for the "unsupported" repository, and make AUR2 a generic pacman package/PKGBUILD web interface, allowing more than one binary/PKGBUILD repository. [1] http://www.github.com/sebnow/parched
On Tue, Feb 03, 2009 at 10:13:19PM +0900, Sebastian wrote:
Hi guys,
I've picked up AUR2 development once again, and made it work with Django 1.0+. I want to start working on binary package support, but I'm unsure as to how to go about it. The current AUR depends on background scripts which populate the database. I really don't like this idea. It's fine for them to exist, but AUR2 should not depend on them. I was thinking of writing a parser for binary packages[1] and using the same upload interface for binary packages as for PKGBUILD packages. Permissions to upload would obviously be restricted to specific groups.
This generalization would also allow me to get get rid of some hard coded logic for the "unsupported" repository, and make AUR2 a generic pacman package/PKGBUILD web interface, allowing more than one binary/PKGBUILD repository.
Parched really looks like something we could use.
On 15/02/2009, at 2:24 AM, Loui Chang wrote:
On Tue, Feb 03, 2009 at 10:13:19PM +0900, Sebastian wrote:
Hi guys,
I've picked up AUR2 development once again, and made it work with Django 1.0+. I want to start working on binary package support, but I'm unsure as to how to go about it. The current AUR depends on background scripts which populate the database. I really don't like this idea. It's fine for them to exist, but AUR2 should not depend on them. I was thinking of writing a parser for binary packages[1] and using the same upload interface for binary packages as for PKGBUILD packages. Permissions to upload would obviously be restricted to specific groups.
This generalization would also allow me to get get rid of some hard coded logic for the "unsupported" repository, and make AUR2 a generic pacman package/PKGBUILD web interface, allowing more than one binary/PKGBUILD repository.
Parched really looks like something we could use.
Hopefully, yeah. I plan on rewriting the PKGBUILD parser as a C extension, so that I can make use of Ragel[1] or some other lexer/ parser. This will make it possible to write a proper parser that understands a subset of Bash (most commonly used things in PKGBUILDs), with less code. Unfortunately this will probably take a while since Ragel seems quite complicated, and I have to learn the cPython API. Hopefully it will be worth it. Maybe even namcap could make use of it. [1]: http://www.complang.org/ragel/
participants (3)
-
Loui Chang
-
Sebastian
-
Sebastian Nowicki