[aur-general] Discussion period - Moving [community] to use same system as main repos

[Aaron Griffin]

On Fri, Jan 9, 2009 at 2:35 PM, Loui Chang <louipc.ist at gmail.com> 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.