[aur-dev] Git repos for AUR packages

William Giokas 1007380 at gmail.com
Thu Jan 9 15:05:07 EST 2014

On Tue, Jan 07, 2014 at 11:03:08AM +0100, Lukas Fleischer wrote:
> Hi,
> I think the idea of integrating Git with the AUR [1] is a very good one
> and should be a milestone for the 3.0.0 release. The idea is to create a
> Git repository per package.
> Pros:
> * Full history of each AUR package, even if the maintainer changes.
> * Lays the foundations for supporting multiple maintainers per package.
> * Makes it easier to contribute patches (see git-format-patch(1),
>   branches and pull requests).
> * cgit might do quite a lot of the work required on the front-end side.
>   PKGBUILD previews, history view, tarball generation, Git clone
>   support, ...

Just looking at the AUR and the official package pages, it looks like
this would bring it much closer to the latter, possibly simplifying
development in the future.

> * Updating packages will be easier (`git pull` followed by `makepkg -i`
>   instead of doing all the work from the web browser or via an AUR
>   helper).

And people can use submodules for large amounts of AUR package!

> Cons:
> * Needs more space on the AUR server. Currently, an AUR package uses
>   ~17KiB on the official Arch Linux AUR server. This will probably
>   increase by a factor of 10. Shouldn't be too problematic unless we get
>   a lot of new packages or a lot of updates.

You could still have a tiny quota for package updates, and git will
compress its contents quite well, especially considering that 99% of
what will be uploaded to the AUR will be plain text files.

> * More load on the AUR server. Especially if we no longer store tarballs
>   but use cgit to generate them on the fly (needs to be discussed).

With caching and the efficiency of cgit, I think that this will be
better than expected.

> Migration should be easy since we can use a small shell script to
> convert all packages into Git repositories.
> The first idea is to slightly change the package submission process to
> extract the whole tarball, parse the PKGBUILD and do a Git commit with
> the tarball content. There will be an additional text field to enter a
> (part of the) commit message that is used. As mentioned above, all
> package repositories will be accessible via cgit. The PKGBUILD preview
> (and maybe also the tarball download) will be replaced with a simple
> link to cgit.
> Later, we should think of how to support support for git-push(1). The
> main issues are
> * Authentication: Virtual accounts, somehow connected to the AUR DB?
SSH keys? Users should be uploading packages from a system that can use
SSH keys, so this shouldn't be an inconvenience to anyone.

> * Integration of the PKGBUILD/.AURINFO parser: Git hook?
> * DoS protection: Quotas, ...
I'd say 2 quotas, one for the update size (files being pushed that will
be the new HEAD) and one for the total repo size (somewhat larger, maybe
1M). As I said in another mail, people can use submodules for
non-PKGBUILD/.install files as well.

William Giokas | KaiSforza | http://kaictl.net/
GnuPG Key: 0x73CD09CF
Fingerprint: F73F 50EF BBE2 9846 8306  E6B8 6902 06D8 73CD 09CF
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mailman.archlinux.org/pipermail/aur-dev/attachments/20140109/1e138555/attachment.asc>

More information about the aur-dev mailing list