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
