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. Regards Stefan