[aur-general] AUR helpers in [community]?
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. -- Kiwis and Limes: http://kaitocracy.blogspot.com/
On 11/18/10 03:30, Kaiting Chen wrote:
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.
No. I looked to see where this was documented on the wiki and the closest I found in a couple minutes was https://wiki.archlinux.org/index.php/Arch_User_Repository#Installing_Package... "Note: There is not and will never be an official mechanism for installing build material from UNSUPPORTED. All users should be familiar with the build process." ...being in [community] makes it too official (although this reasoning is not trivially obvious from the quote). It makes it possible to install the AUR Helper without ever having that moment of experience/familiarity using makepkg (to draw from the quote's second sentence). -Isaac
On 11/18/2010 10:30 AM, Kaiting Chen wrote:
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.
no. we can't support unsupported software :P -- Ionuț
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. I would have nothing against having tools like this in [community]. But everything beyond that should be strictly rejected. Regards Stefan
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 -- Ionuț
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
Slurpy already does that... *download, searches, and uploads *created by rson *maintained by our very own, MrElendig. *No build support *Written in Python! https://github.com/rson/slurpy
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
On 18 November 2010 16:30, Kaiting Chen <kaitocracy@gmail.com> wrote:
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.
Good that you asked. Otherwise, you could've made a wrong move. 1) AUR build helpers The AUR is an "unsupported" repository. You should know what that entails. Supporting such tools indirectly integrates them into the system, creating misunderstandings which we do not want to deal with. 2) AUR search helpers This is similar to the above. They communicate with a database which may be mistakenly assumed to be (semi-)supported. 3) AUR upload/download helpers Same as well. So, IMO, it is best that such tools, regardless of the extent of features, be left in AUR. I myself use slurpy for upload, and rarely do I use the search/download features :)
On Fri, Nov 19, 2010 at 04:43:15AM +0800, Ray Rashif wrote:
So, IMO, it is best that such tools, regardless of the extent of features, be left in AUR. I myself use slurpy for upload, and rarely do I use the search/download features :)
I basically agree. The AUR is unsupported and has nothing to do with Arch Linux or the [community] repository. Imho, it's as if we'd move dpkg and/or rpm from [unsupported] to [community] (to a certain extent, at least). Both of them have more than 100 votes but are not moved since we don't want alternative package managers in the repos. There's no other convincing reason for that. They are just unsupported. Moreover, if people use packages from the AUR so extensively that they need AUR helpers, they should be fine with building one more package from source, shouldn't they? (Don't take that last sentence too serious. Please.)
Am Thu, 18 Nov 2010 22:20:01 +0100 schrieb Lukas Fleischer <archlinux@cryptocrack.de>:
I basically agree. The AUR is unsupported and has nothing to do with Arch Linux or the [community] repository.
Since when doesn't have AUR anything to do with Arch Linux or [community] repo? AUR is totally Arch Linux related and can only be used with Arch Linux. And [community] repo is the repo where AUR packages go when they got enough votes and a TU interested in maintaining them.
Both of them have more than 100 votes but are not moved since we don't want alternative package managers in the repos. There's no other convincing reason for that. They are just unsupported.
AUR wrappers are not added to the repos for security reasons as far as I know. It's because users may tend to not reading and validating the PKGBUILDs and install scripts, which can be uploaded to AUR by everyone without being validated by a dev or TU, if they use such a wrapper. Keyword: rm -rf / Maybe they are also not added because neither devs nor TUs can ensure that they are always working correctly. I'm not sure if there are other reasons, too.
Moreover, if people use packages from the AUR so extensively that they need AUR helpers, they should be fine with building one more package from source, shouldn't they? (Don't take that last sentence too serious. Please.)
In this point I agree. Heiko
On Thu, Nov 18, 2010 at 11:28:31PM +0100, Heiko Baums wrote:
I basically agree. The AUR is unsupported and has nothing to do with Arch Linux or the [community] repository.
Since when doesn't have AUR anything to do with Arch Linux or [community] repo? AUR is totally Arch Linux related and can only be used with Arch Linux. And [community] repo is the repo where AUR packages go when they got enough votes and a TU interested in maintaining them.
"nothing to do" meaning that it's not part of the official project of course.
On Fri 19 Nov 2010 04:43 +0800, Ray Rashif wrote:
On 18 November 2010 16:30, Kaiting Chen <kaitocracy@gmail.com> wrote:
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.
So, IMO, it is best that such tools, regardless of the extent of features, be left in AUR. I myself use slurpy for upload, and rarely do I use the search/download features :)
I agree. Keep the AUR tools in the AUR where they belong.
On 19/11/10 10:54, Loui Chang wrote:
On Fri 19 Nov 2010 04:43 +0800, Ray Rashif wrote:
On 18 November 2010 16:30, Kaiting Chen<kaitocracy@gmail.com> wrote:
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.
So, IMO, it is best that such tools, regardless of the extent of features, be left in AUR. I myself use slurpy for upload, and rarely do I use the search/download features :)
I agree. Keep the AUR tools in the AUR where they belong.
Also, this enforces everyone to have some actual idea what their AUR helper is doing...
participants (10)
-
Allan McRae
-
Heiko Baums
-
Ionuț Bîru
-
Isaac Dupree
-
Kaiting Chen
-
Loui Chang
-
Lukas Fleischer
-
Matthew Gyurgyik
-
Ray Rashif
-
Stefan Husmann