Re: [aur-general] [arch-dev-public] Breaking the unspoken rule: AUR helper in [community]
On 12/30/2010 04:16 AM, Dan McGee wrote:
http://www.archlinux.org/packages/community/i686/cower/
Thoughts? I was under the impression we didn't do this, and definitely on purpose, otherwise people have *no* idea the AUR is different in a lot of ways. Making people go the "hard way" to get a helper installed at least presents some (necessary) barrier.
-Dan
this is my mistake suggesting him to push it community mostly because cower is not like yaourt. It doesn't help building anything and users still have to familiar themselves with PKGBUILD and makepkg. i consider cower being a cli interface from aur and it much better than the html version. with it i can found more easily packages because it has bash completion, searching has regex. Just try to find the link for opera build from aur using the html interface vs cower. The only "rule" i found in wikis about this subject is: 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. Maybe we should change that and include all aur helpers that interface with the official json api from aur.archlinux.org. -- Ionuț
Ionuț Bîru wrote:
Maybe we should change that and include all aur helpers that interface with the official json api from aur.archlinux.org.
I would only restrict applications that download from (and maybe upload to) the AUR. There may be acceptable uses of the API beyond that, such as a generic search application that checks repos and the AUR, e.g. $ findpkg foo foo is in the AUR: <url> That would still make the package origin clear and require the user to understand how the AUR and ABS work, and it does not present any security risks.
On 30 December 2010 20:45, Xyne
Ionuț Bîru wrote:
Maybe we should change that and include all aur helpers that interface with the official json api from aur.archlinux.org.
I would only restrict applications that download from (and maybe upload to) the AUR. There may be acceptable uses of the API beyond that, such as a generic search application that checks repos and the AUR, e.g.
$ findpkg foo foo is in the AUR: <url>
That would still make the package origin clear and require the user to understand how the AUR and ABS work, and it does not present any security risks.
Searching, downloading, or uploading - all communicate with the AUR and provide the user with an alternative interface. This "integrates" the AUR into the distribution, to some extent. * john installs archlinux * john installs aursearch * john searches aur * john realises there is no download or build helper he can install * john complains and demands for a helper in the repos, citing the search helper as useless However, a search tool is pretty trivial and I don't see any other problems aside from complaints like the above. IMHO a search tool can be kept in our repos. However, a download tool asks for more trouble. For instance: "Hi..I have a problem with barsoft. Downloaded and installed in archlinux" "What? Didn't we say NOT to redistribute our software? archlinux is now in the hall of shame." We currently have the defense that the AUR is _completely_ decoupled. This has allowed us to have all sorts of things in there. The only action one can take on a PKGBUILD is to access the AUR, personally or by means of third-party, unsupported utilities. As for an upload tool, I don't see any immediate issue. It's got nothing to do with anything but putting up files. But one case where it might pose a problem is if someone decided we're bad for letting users upload their restricted non-redistributable software. We would also not have the completely-decoupled defense in the event of a dispute.
On Thu 30 Dec 2010 14:26 +0200, Ionuț Bîru wrote:
On 12/30/2010 04:16 AM, Dan McGee wrote:
http://www.archlinux.org/packages/community/i686/cower/
Thoughts? I was under the impression we didn't do this, and definitely on purpose, otherwise people have *no* idea the AUR is different in a lot of ways. Making people go the "hard way" to get a helper installed at least presents some (necessary) barrier.
i consider cower being a cli interface from aur and it much better than the html version. with it i can found more easily packages because it has bash completion, searching has regex. Just try to find the link for opera build from aur using the html interface vs cower.
Opera is in [community] I believe. If we do want to adopt an 'official' AUR client then we should present it on the AUR web page, and put it in the git repo along with the server scripts, rather than putting it on [community].
The only "rule" i found in wikis about this subject is:
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.
Maybe we should change that and include all aur helpers that interface with the official json api from aur.archlinux.org.
Yeah I think we should make an explicit rule to say that no programs that purposely interface with the AUR will be in [community] or an official repo. This way we don't need to have debates on what kind of programs are kosher or not.
participants (4)
-
Ionuț Bîru
-
Loui Chang
-
Ray Rashif
-
Xyne