[aur-dev] AUR2

[Sebastian Nowicki]

On Mon, Oct 26, 2009 at 6:58 AM, Ryan Coyner <rcoyner at gmail.com> wrote:

>> > I think for the time being, simply porting the current AUR (with some
>> > modifications) to a new, more flexible and maintainable system is
>> > critical. It should be much easier to change implementation details
>> > later.
>> >
>> >
>> Yeah, but the principle is to be as compatible with the 'old' AUR as we
>> can,
>> so most of the informations from the database is good to follow.
>>
>
> By more flexible and maintanable, I'm assuming the implementation of an API
> (to allow clean, command line and web access) and the port of the web
> interface to Django which is definitely a much more maintainable framework.
>
> +1 for this notion.

Yes. The Django port is fairly far along, and the API I mentioned
earlier should allow for all tasks to be carried out by 3rd part
clients.

> Regarding JSON/Makefile, I was suggesting that we dump the PKGBUILD format
> altogether and use JSON to carry the metadata and a Makefile to substitute
> for the build function. Now, to draw some comparisons:
>
> Advantages of the PKGBUILD format:
>
> 1) It's a simple format allows new users to easily contribute to the AUR.
> 2) It encapsulates both metadata and build instructions in a single file.
> Again, promotes simplicity for the user.
> 3) No need to hack up makepkg.

4) The format allows for variables and control structures. This could
be implemented (at least variables) with JSON, but then we no longer
have JSON advantage #1. Being able to use $pkgname and $pkgver is
_very_ useful.

If we want to change the PKGBUILD format, we have to take it up with
makepkg devs, and see what they think about it. I think it's unlikely
that they will want to change anything. The current format servers its
purpose well.

> One thing to note is licenses. Some software have custom licenses - how is
> that going to be represented?

A url field pointing to the license?

> Another thing to keep in mind is possible
> integration of the user accounts with other services for the future (bugs,
> forums, etc). It would be ideal if the schema is scalable enough to take
> that into factor.

I think this is out of AUR's scope. I generally see AUR (at least the
frontend) as a generic package browser - just like the one on the main
page. It shouldn't integrate, or even care about other
Archlinux-specific services.

The current schema is just taken from the Django AUR2 app, and the
account schema is from Django's built-in auth app. As far as Django
goes, it's already scalable (all other apps use the same data). I'm
not sure how one would make it more scalable to integrate with other
web apps - they aren't consistent in that respect.