On Fri, Jan 9, 2009 at 2:35 PM, Loui Chang firstname.lastname@example.org wrote:
*You'd lose votes for community packages.
- You'd lose package comments and notifications.
Ok, those may not be completely true. My fault. I'll edit the wiki. We we can still keep community packages in the AUR interface, but I was assuming that the proposal was to ditch them. It will just take a bit of patching to keep them.
This is also important to me. It is much easier to write a comment than to use a bugtracker for users.
- Combining community packages with official packages will contribute a
performance hit for all repos when dealing with >build files.
Cannot comment because i do not get the point.
Well, the way the arch SVN repo for build files is organised is by packages, not by repos. That means all community packages will be thrown in together with core, extra, and testing packages.
To get a checkout of community you would have to scan every package directory to see if it's actually in community. I'm not sure if it's possible via standard subversion tools either.
I'm not sure what you mean here. The official repos did away with the "scan all packages" thing a while back. There's no need to regenerate an entire list of all packages, assuming we maintain state properly. Every operation is an add or a remove. We simply use SVN to ensure that the package belongs in that repo.
So when I say "ok, let's add openssh to core", the tools make sure we have a PKGBUILD listed in "openssh/repos/core-i686". If it's there, it makes sure the versions are the same. If all is well, the package is added to the DB.
The web interface uses a DB that is based on pacman's DB. There is a cron job that grabs the current "core.db.tar.gz" that pacman uses, and simply dumps it into a mysql DB for use by the front end.