[aur-dev] Git repositories for AUR packages

Kuba Serafinowski zizzfizzix at gmail.com
Thu Jun 5 12:35:53 EDT 2014

> Hi list,
> The next major AUR release will come with Git integration. In this
> email, I am going to summarize previous ideas and make things a bit more
> concrete (sketch implementation details etc.)
> If you are new to this topic, please read [1] and [2] first.
> Our plan is to create one Git repository per package base. Each of the
> Git repositories contains a PKGBUILD and zero or more additionally
> required files, so you will no longer need to build a source tarball.
> There will be a pkgbuild-introspection utility to generate and write
> .AURINFO metadata without automatically putting that file inside the
> tarball. Florian had the idea to use a shared Git object database for
> space efficiency.
> When creating a new account, users will be able to upload an SSH public
> key. This key will be stored in the AUR database and can also be changed
> using the profile edit page. Using this public key, users will be able
> to push to repositories they maintain using Git over SSH. For
> authentication, a custom script doing a lookup in the AUR user database
> will be used as AuthorizedKeysCommand. If a matching key is found, that
> script prints the corresponding authorized_keys line with a forced
> command that invokes a wrapper around the Git shell. That wrapper in
> turn does authorization by checking maintainership and then calls
> git-shell(1).
> Using Git hooks, the .AURINFO metadata of a package is parsed when
> pushing and the AUR package database is updated accordingly. Hooks will
> also take care of checking the tree objects for huge files etc. The
> receive.denyNonFastForwards configuration option will be enabled to
> prevent users from rewriting the history.
> In order to submit new packages, you will be able to generate empty Git
> repositories via the AUR web interface. During the transition period,
> all existing source tarballs will be converted to bare repositories with
> one initial commit whose tree equals the tarball contents.
As has been suggested in either [1] or [2] thread, can we get initial
importing of git history?
I personally haven't been using the same scheme for version control, but
from what I've read it's quite simple to separate a directory into its own
repository, maintaining the commit history.
It would be really nice to have, to be able to fully migrate off of
personal solutions without losing anything.
> Instead of the source tarball download link and the PKGBUILD preview,
> there will be a public clone URL on the package details page. In a
> second step, cgit will be configured to provide a web-based interface to
> all the repositories. Then, links to tarball snapshots and to the
> PKGBUILD preview will be added to the details page as a replacement for
> the "Download tarball" and "View PKGBUILD" links (all this is supposed
> to happen before the first release).
> As soon as all this is set up, we can add support for multiple
> maintainers and related features.
> If there are any questions or suggestions regarding this setup, please
> feel free to ask/reply.
> Regards,
> Lukas
> [1] https://mailman.archlinux.org/pipermail/aur-dev/2013-March/002411.html
> [2]


More information about the aur-dev mailing list