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. Thanks, -- William Giokas | KaiSforza | http://kaictl.net/ GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF
pgp6Jx2IqJpZb.pgp
Description: PGP signature
