[aur-general] aur-general Digest, Vol 49, Issue 17

[Abdul Halim]

The community repository should still exist as there several packages
that i use daily or weekly in fact such as amsn, dar, openobex, obexfs, compiz.

Please don't remove the repository as i would like to see my daily applications
being updated and easily downloaded.

There are also some other useful package in community repository that
i would like to try
and not easily available from the previous distro I use. It is just 3
months that
I have use Arch linux and I have yet to exploit the full power and
unlimited possibilities of Arch
linux. :-(


On Tue, Nov 11, 2008 at 9:39 AM,  <aur-general-request at archlinux.org> wrote:
> Send aur-general mailing list submissions to
>        aur-general at archlinux.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://archlinux.org/mailman/listinfo/aur-general
> or, via email, send a message with subject or body 'help' to
>        aur-general-request at archlinux.org
>
> You can reach the person managing the list at
>        aur-general-owner at archlinux.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of aur-general digest..."
>
>
> Today's Topics:
>
>   1. Re: Packages in Community and votes. (Aaron Griffin)
>   2. Re: pkgstats and community - attempt 2 (Ond?ej Ku?era)
>   3. Re: pkgstats and community - attempt 2 (Brandon Martin)
>   4. Re: pkgstats and community - attempt 2 (Ronald van Haren)
>   5. Re: Packages in Community and votes. (Aaron Schaefer)
>   6. Re: Packages in Community and votes. (Loui Chang)
>   7. Re: Packages in Community and votes. (Aaron Schaefer)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 10 Nov 2008 17:05:40 -0600
> From: "Aaron Griffin" <aaronmgriffin at gmail.com>
> Subject: Re: [aur-general] Packages in Community and votes.
> To: "Discussion about the Arch User Repository (AUR)"
>        <aur-general at archlinux.org>
> Message-ID:
>        <d64a48980811101505g3a970bedtaaf399e460ed1da1 at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Mon, Nov 10, 2008 at 4:32 PM, Daenyth Blank <daenyth+arch at gmail.com> wrote:
>> 1) The server is being strained (what parts exactly?) by the community repo.
>
> It's primarily disk space and IO load issues.
>
> The community repo and AUR are fairly large. A cron job which WAS
> keeping the AUR's permissions in check was actually pegging our system
> with so much load that we had to remove any handling of the AUR files
> (hope the code is good enough for that).
>
> The AUR backend daemon opens every single package file (wtf?) when it
> runs, which is a HUGE resource hog. In an ideal world, someone would
> rewrite this to work the same way the offical repos work - with
> repo-add and a separate decoupled script to load the mysql database
> from a pacman DB.
>
> Sizes on disk:
>   community: 11G
>   extra: 11G
>   core: 330M
>   unsupported: 800M
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 11 Nov 2008 00:17:20 +0100
> From: Ond?ej Ku?era <ondrej.kucera at centrum.cz>
> Subject: Re: [aur-general] pkgstats and community - attempt 2
> To: "Discussion about the Arch User Repository (AUR)"
>        <aur-general at archlinux.org>
> Message-ID: <4918C100.30907 at centrum.cz>
> Content-Type: text/plain; charset=ISO-8859-2; format=flowed
>
> Hi,
>
> Allan McRae wrote:
>> So lets start there.  What should the [community] repo be doing?  What
>> is its purpose?   There is no point discussing anything else until that
>> is well defined.
>> All responses must start with "The [community] repo is ..."
>
> The [community] repo is - in my non-dev, non-TU very humble opinion - a
> repository for packages that are perhaps not as widely used as those in
> [core] or those in [extra] but still used by enough users, so that it's
> reasonable to provide them in binary form, providing that there is a way
> to do so. I always figured that there is only so many devs and only so
> many packages a single dev can maintain, which leads to a limited number
> of packages in [core]/[extra]. That's why there are TUs and that's why
> there is [community] - so that the number of packages provided in binary
> form (by people that hopefully can be trusted) is larger.
>
> But what I actually wanted most to say was "amen" to your e-mail, Allan,
> I think you've summarized feelings of many people...
>
> Ond?ej
>
>
> --
> Cheers,
> Ond?ej Ku?era
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 10 Nov 2008 17:23:43 -0600
> From: Brandon Martin <bmartin at cu3edweb.com>
> Subject: Re: [aur-general] pkgstats and community - attempt 2
> To: "Discussion about the Arch User Repository (AUR)"
>        <aur-general at archlinux.org>
> Message-ID: <afeffc3803b972349e442188e1eae9cf at cu3edweb.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Tue, 11 Nov 2008 00:17:20 +0100, Ond?ej Ku?era
> <ondrej.kucera at centrum.cz> wrote:
>> Hi,
>>
>> Allan McRae wrote:
>>> So lets start there.  What should the [community] repo be doing?  What
>>> is its purpose?   There is no point discussing anything else until that
>>> is well defined.
>>> All responses must start with "The [community] repo is ..."
>>
>> The [community] repo is - in my non-dev, non-TU very humble opinion - a
>> repository for packages that are perhaps not as widely used as those in
>> [core] or those in [extra] but still used by enough users, so that it's
>> reasonable to provide them in binary form, providing that there is a way
>> to do so. I always figured that there is only so many devs and only so
>> many packages a single dev can maintain, which leads to a limited number
>> of packages in [core]/[extra]. That's why there are TUs and that's why
>> there is [community] - so that the number of packages provided in binary
>> form (by people that hopefully can be trusted) is larger.
>>
>> But what I actually wanted most to say was "amen" to your e-mail, Allan,
>> I think you've summarized feelings of many people...
>
> The [community] repo is -
>
> Very well put this is what I thougth the community repo was for also.
>
> --
> Brandon Martin
>
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 11 Nov 2008 01:17:09 +0100
> From: "Ronald van Haren" <pressh at gmail.com>
> Subject: Re: [aur-general] pkgstats and community - attempt 2
> To: "Discussion about the Arch User Repository (AUR)"
>        <aur-general at archlinux.org>
> Message-ID:
>        <9fcf70360811101617h422b2615r5abd64eb2b064900 at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-2
>
> 2008/11/11 Ond?ej Ku?era <ondrej.kucera at centrum.cz>:
>> Hi,
>>
>> Allan McRae wrote:
>>>
>>> So lets start there.  What should the [community] repo be doing?  What is
>>> its purpose?   There is no point discussing anything else until that is well
>>> defined.
>>> All responses must start with "The [community] repo is ..."
>>
>> The [community] repo is - in my non-dev, non-TU very humble opinion - a
>> repository for packages that are perhaps not as widely used as those in
>> [core] or those in [extra] but still used by enough users, so that it's
>> reasonable to provide them in binary form, providing that there is a way to
>> do so. I always figured that there is only so many devs and only so many
>> packages a single dev can maintain, which leads to a limited number of
>> packages in [core]/[extra]. That's why there are TUs and that's why there is
>> [community] - so that the number of packages provided in binary form (by
>> people that hopefully can be trusted) is larger.
>>
>> But what I actually wanted most to say was "amen" to your e-mail, Allan, I
>> think you've summarized feelings of many people...
>>
>> Ond?ej
>>
>>
>> --
>> Cheers,
>> Ond?ej Ku?era
>>
>
> IMO all that but without your last argument. Quite some TUs are also
> Devs at this very moment, so for the workload for them it doesn't
> matter. Still most of the packages they maintain should stay in
> community. Packages in community should be there because they are used
> by quite some people, but not enough to have them in extra, or
> packages that are a hype and have to prove that they are there to stay
> before they are put into extra (bmpx in extra comes to mind which
> development has stopped after like little over 1 year (?),just an
> example to make clear what I mean). Alpha software (for example e17)
> should also never be included in extra IMO (though some packages may
> not follow this rule if needed).
>
> Hope it is clear enough, it's already late :p
>
> Ronald
>
> ------------------------------
>
> Message: 5
> Date: Mon, 10 Nov 2008 19:22:01 -0500
> From: "Aaron Schaefer" <aaron at elasticdog.com>
> Subject: Re: [aur-general] Packages in Community and votes.
> To: "Discussion about the Arch User Repository (AUR)"
>        <aur-general at archlinux.org>
> Message-ID:
>        <e36e8c790811101622oeb928f9q25e3b0d908ba49d7 at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
>> 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
> solutions.
>
> --
> Aaron "ElasticDog" Schaefer
>
>
> ------------------------------
>
> Message: 6
> Date: Mon, 10 Nov 2008 20:00:10 -0500
> From: Loui Chang <louipc.ist at gmail.com>
> Subject: Re: [aur-general] Packages in Community and votes.
> To: "Discussion about the Arch User Repository (AUR)"
>        <aur-general at archlinux.org>
> Message-ID: <20081111010010.GK1071 at lynn.lan>
> Content-Type: text/plain; charset=us-ascii
>
> On Mon, Nov 10, 2008 at 07:22:01PM -0500, Aaron Schaefer wrote:
>> > 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
>> solutions.
>
> I've said this already in discussions but I'll say this again.
> Fixing the community back end, removing large packages, and removing
> unused packages are all possible solutions to the problem.
>
> If we implement all the solutions, then we get an incremental
> improvment. Each solution will build upon the others. We shouldn't only
> implement one measure. We should implement ALL measures within reason.
>
> I only raised the issue of unused or barely used packages in Community
> and pruning the repo. We should really be focusing on that before
> diverting the discussion and delving into other areas.
>
> http://wiki.archlinux.org/index.php/Community
>
>
>
> ------------------------------
>
> Message: 7
> Date: Mon, 10 Nov 2008 20:39:25 -0500
> From: "Aaron Schaefer" <aaron at elasticdog.com>
> Subject: Re: [aur-general] Packages in Community and votes.
> To: "Discussion about the Arch User Repository (AUR)"
>        <aur-general at archlinux.org>
> Message-ID:
>        <e36e8c790811101739g413cc24dvb86c5fa00bc877ae at mail.gmail.com>
> Content-Type: text/plain; charset=UTF-8
>
> On Mon, Nov 10, 2008 at 8:00 PM, Loui Chang <louipc.ist at gmail.com> wrote:
>> I only raised the issue of unused or barely used packages in Community
>> and pruning the repo. We should really be focusing on that before
>> diverting the discussion and delving into other areas.
>
> I know we've discussed this in IRC, but again my question is _why_
> should this be the focus? Does it give us the most improvement for the
> least effort? Does it inconvenience users the least? Is it the
> cheapest? By how much? Is it the fastest? Why? Why? Why?
>
> I'm open-minded about suggestions, but need something more substantial
> to back them up than just saying "we should do this". Where are the
> numbers to support the claim? Also, it seems as though the issue of
> popularity/voting and the community repo might be altogether different
> than the issue of server resources. Are we linking the two together
> because of a twist of fate with timing and pkgstats coming to
> fruition?
>
>
> Aaron "ElasticDog" Schaefer
>
> p.s. my link for package sizes will disappear in a day, here's a
> better one: http://omploader.org/vd3Vx
> --
>
>
> ------------------------------
>
> _______________________________________________
> aur-general mailing list
> aur-general at archlinux.org
> http://archlinux.org/mailman/listinfo/aur-general
>
>
> End of aur-general Digest, Vol 49, Issue 17
> *******************************************
>