> 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] https://mailman.archlinux.org/pipermail/aur-dev/2014-January/002592.html
Cheers Kuba
