[aur-general] Packages in Community and votes.

Aaron Schaefer aaron at elasticdog.com
Mon Nov 10 19:22:01 EST 2008

> It's primarily disk space and IO load issues.

I have questions, mostly meant to get people thinking about
alternatives and ramifications of any solutions...

If the real issue is disk space and IO, what about the possibility of
a hardware upgrade? What about moving the largest packages to
unsupported (or something like arch-games) instead of basing it on
votes? It looks like eliminating just the top 10 largest community
packages would save 1.8 GB of space! See
http://rafb.net/p/Xfw0gh39.html for package sizes. What about putting
community on it's own server? What about fixing the AUR backend? What
about adding a CVS commit hook in the mean time to fix permissions on
upload instead of running a single cron job?

If we make these proposed changes, how will they actually impact the
server and it's current problems? How will they effect Arch users?
What is the price of convenience that the community repo provides to
Arch users? Will there be a way to easily differentiate packages in
unsupported that are actually maintained by TUs? How can we reliably
tell what is popular? Download numbers, voting, pkgstats, etc. all
have their own issues and biases...is there a better way? What makes
the most sense in the long run when there are sure to be more TUs and
packages in community eventually? Should we worry about things that
are currently in community, or just new packages?

My main point is that there are many options, and any solution that
gets acted upon needs to be based on hard evidence for improvement and
account for all consequences of that change rather than just basing it
on what sounds good. There has been a lot of rabble-rousing and not
much investigation into the underlying problems and proposed

Aaron "ElasticDog" Schaefer

More information about the aur-general mailing list