[aur-general] AUR helpers in [community]?
stefan-husmann at t-online.de
Thu Nov 18 21:10:24 CET 2010
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.
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.
More information about the aur-general