On 30 December 2010 20:45, Xyne <xyne@archlinux.ca> wrote:
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.