[aur-general] AUR helpers in [community]?

[Stefan Husmann]

Am 18.11.2010 20:31, schrieb Matthew Gyurgyik:
> On 11/18/2010 02:03 PM, Ionuț Bîru wrote:
>> On 11/18/2010 09:00 PM, Stefan Husmann wrote:
>>> Am 18.11.2010 09:30, schrieb Kaiting Chen:
>>>> Can AUR helpers go into [community]? `burp` and `cower` each have over ten
>>>> votes and qualify, but I never see AUR helpers in binary form so I thought I
>>>> would ask. --Kaiting.
>>>>
>>>
>>> I think if we should discuss this if the AUR helper does not hide the build
>>> process itself from the user. Cower for instance is for just downloading the
>>> taurball (you still have to run makepkg manually), and burp is for just
>>> uploading it.
>>
>> two tools for managing aur is not what we want.
>>
>> maybe cower could get upload support too
>>
I definitely prefer two tools for uploading and downloading. In fact I only use 
burp for uploading, and not cower but aurdownload (in aurscripts) for downloading.

> Slurpy already does that...
>   *download, searches, and uploads
I know slurpy, but I am not totally convinced. It does not fit to my workflow. I 
have two directory-trees where my PKGBUILDs live, and slurpy is only aware of one
of them (the one you cd to).
>   *created by rson
Who is this? Do I need to know him or her?
>   *maintained by our very own, MrElendig.
Also cower and burp are made by an archer.
>   *No build support
That is okay!
>   *Written in Python!
> 
That is a disadvantage over cower and burp, which are written in C. 
> 
> https://github.com/rson/slurpy
> 
Never mind, it is not completely unusable.

But the problem is not which tool we want to have in [community] but to make 
up a rule what kind of help such a helper might provide to be seen as candidate 
for inclusion in [community]. I tried to propose an criterium in my previous post.

Regards Stefan