[aur-dev] Git repositories for AUR packages

郑文辉(Techlive Zheng) techlivezheng at gmail.com
Tue Jun 24 03:20:08 EDT 2014


2014-06-03 1:08 GMT+08:00 Lukas Fleischer <archlinux at cryptocrack.de>:
> 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.)
>

It is really glad to see this feature is about to take shape.

> 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.
>

So, this means, all the maintainers have to use git to submit
packages? Any thought on keeping the old package submission form and
proceed the commit process on the server? which will allow normal
people to contribute packages.

> 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.
>
> 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.
>

Any thought on package history policy? Does the maintainer to be
allowed to rewrite/alter the git history of package? As far as I know,
git does not forbid this kind of things, so, what if a ill-intended
guy replace the history of a package with his well-crafted history,
and completely wiped out the change log of the original package? What
is our pollicy or measures on this? From my point of the view, the
history of a package is the essiential part of the AUR, which we can
know hos the package is envolved and perfacted.

> 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


More information about the aur-dev mailing list