1. 5M is probably an overkill. I think 1-2M is usually enough. There are simply patches and PKGBUILD 2. https://github.com/libgit2/php-git 3. I can help if anyone needs to code in php
side notes: why dont we have package deletion for maintainer?? On Sat, Mar 16, 2013 at 3:10 PM, William Giokas <[email protected]> wrote: > All, > > So in my spare time I was thinking about the AUR and how it could be > better. Back in January I commented on a bug[1] about integrating the > AUR and git to have a powerful, robust backend for the AUR. I think that > the original idea of creating one massive repository was inherently > flawed for most users, as it requires that the entire repository be > cloned, and that is no trivial task for people with only moderate > internet speeds. Were it similar to the way the official repositories > git setup is, then it would be okay for fetching, but using single > repositories for each project would make access control much less of a > nightmare. > > At the moment I have no experience with PHP or messing with the AUR, but > I have been playing around with git and using it to track packages and > the like, as well as some minimal experience with access control and > git. > > Currently, this is kind of the roadmap I see in my head: > > * Set up access controls for the AUR users to access over ssh using > keys. While I could see this being somewhat arduous, it shouldn't be > terribly hard to automate or set up. Something like gitolite or > whatever should make it simpler. > * Each repository on the server would contain a single package (if > someone decides to do a split package on the AUR it would contain the > whole set of packages), allowing for multiple users to have push > access and maintain the packages. > * The repositories would be limited to 5M, unless given special > permission (certain kernel packages with lots of massive configuration > files) which should make enough room for the needed files, while > helping to enforce the idea of not putting retrievable sources in the > source tarball. I did some quick math using the number of packages on > the AUR right now, and if every repo used that 5M limit, it would > require a bit over 200G. Granted, I doubt that this limit would be > reached for most packages. > * With the repository set up, give maintainers a week or so to upload > history for their packages (in case they already keep their repos in > this set up), and new packages would get put directly into a new repo. > * Once the week for transition is over, begin moving all of the current > packages in the AUR to the git format. > > This basically concludes setting up the git stuff, which I have done on > a local machine on a very small scale (5 packages) in the past. One > thing I was thinking of was the use of `makepkg -S` tarballs still being > available. cryptocrack came up with a good point, that just simply > copying things over could overwrite the .git directory in the designated > directory. I don't think that would be too hard to get around, but I'm no > expert. I wrote a quick and dirty script that extracts and commits to > the respective repository. Currently, almost no packages use a > .changelog file, but there could be some minimal parsing done of a > packages .changelog file to craft a git commit message from a tarball. > Obviously there needs to be some kind of security check, but that could be > done by the frontend using the system we have now for source tarballs. > > At the moment, I am unsure exactly how the AUR parses the PKGBUILDs it > receives, but I'm sure that this could easily be adapted to the git > system. > > One major advantage to having the AUR managed this way is that it would > allow users to check for updates on the AUR without the need for complex > helpers outside of git. Secondly, it would make mirroring the AUR, or > just parts of the AUR extremely easy. In case something happens to the > AUR, people can still get their packages and maintainers can still > update them very easily using git. It would also still allow people to > grab tarballs of the current master branch. This way git is not a > requirement to use the AUR, it just makes things a butt ton easier. > Also, it would allow users to see the entire source of the package, not > just the PKGBUILD, similar to how the official repository works, just > that things would be in distinct git repositories not branches. > > I would really like to see this kind of thing come to fruition, and if > anyone would be willing to help, then please say so. > > > Pardon my scattered thoughts, > -- > William Giokas | KaiSforza > GnuPG Key: 0x73CD09CF > Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF > > [1]: https://bugs.archlinux.org/task/23010
