On Fri, Jan 9, 2009 at 2:35 PM, Loui Chang <[email protected]> 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.
