[aur-dev] Git repos for AUR packages

[William Giokas]

All,

I think that everyone has been looking at gitorious and gitlab, the main
systems with front-ends for their users. We already have a front-end for
our users, all we need is the backend. I have given it some thought
previously (if you want, look up the mail), and one of the best
solutions seems to be gitolite[1]. We would need a way to work with the
permission config files based on AUR users signing up and uploading
files, however I think that this is doable.

On Thu, Jan 09, 2014 at 07:10:27PM +0800, Techlive Zheng wrote:
> on 14-01-09, techlive zheng wrote:
> > I don't think we should support `git-push` at all, the reasons are
> > simple:
> >
> > * Git allows overwriting the history by doing a force push `git push -f`.
> >   As a community PKGBUILD publishing platform, the git history of a PKGBUILD
> >   should not be allowed to be tampered with, whether accidently or
> >   intentionally, it should reflect how the PKGBUILD envloved from the start,
> >   not the one someone carefully crafted.
> >
> > * Changed history will cause conflit on `git pull`, which is not something we
> >   want to deal with everyday.
> >
> > Instead, we should stick on the `src.tar.gz` tarball submitting, and make the
> > Git commit on the server.
> >
> > At least, push access should not be granted to normal user, only to TUs.
> >

All of this can be disabled in any good git management platform, I know
gitolite does. We could use the aur-dev mailing list to request
force-pushes if need be.

> 
> Also, if we allow normal user to push directly with Git, it will be
> harder to do sanity check. One can push anything, not just the packaging
> files, but anything, binaries, compressed source/build tarballs, even
> files unrelated to Arch packaging at all. These malformed files can
> exist not only in the Git HEAD, but can be intentionally hided in the
> history, makes it hard to control the space quotas.

Not really. We can use git hooks to check the size of the files that are
pushed, and it won't make it any harder to control space quotas. If the
repository goes over a couple of megabytes, then they can't push. End of
story.

Another thing that people can do is use submodules[2] in their AUR
repositories if they have some kind of binary file they can't get rid
of. This would keep the size on the AUR down while also allowing them to
have a 4M image in their AUR package.

> We'd better only access 'src.tar.gz' tarball and control the commit
> process on the server on our own, so that we can do necessary sanity
> check to ensure files to be commited are really what they claim to be.

While this is an option, I don't think that the arguments above make it
the better option of the two. In fact, something that we may want to
look into is keeping the legacy .src.tar.gz files around, but also
having users with the ability to `git push` to their repositories.

[1]: http://gitolite.com/gitolite/index.html
[2]: http://git-scm.com/book/en/Git-Tools-Submodules

Thanks,

-- 
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/b9cc381f/attachment.asc>