FS#13026 - {archweb} Add a json interface for ABS as we have for AUR
Attached to Project:
Arch Linux
Opened by Xyne (Xyne) - Wednesday, 28 January 2009, 19:50 GMT
Last edited by Eli Schwartz (eschwartz) - Wednesday, 03 January 2018, 16:47 GMT
Opened by Xyne (Xyne) - Wednesday, 28 January 2009, 19:50 GMT
Last edited by Eli Schwartz (eschwartz) - Wednesday, 03 January 2018, 16:47 GMT
|
Details
There is an AUR json interface (sorry if that's not the
right terminology).
http://aur.archlinux.org/rpc.php This enables scripts to retrieve package info such as version numbers and tarball URLs for downloading and building AUR pkgs. It would be nice to have a similar interface for the official ABS packages. "abs" is not a direct alternative as this requires the user to keep the entire ABS tree on the local machine which reduces portability and also requires more server and client bandwidth due to regular rsyncs. Having a scripting interface and the ability to selectively retrieve PKGBUILDs would be much more flexible. |
This task depends upon
Closed by Eli Schwartz (eschwartz)
Wednesday, 03 January 2018, 16:47 GMT
Reason for closing: Won't implement
Additional comments about closing: ABS has been dropped, and [extra]/asp is the recommended tool for getting up to date PKGBUILDs via per-package svntogit branches.
Wednesday, 03 January 2018, 16:47 GMT
Reason for closing: Won't implement
Additional comments about closing: ABS has been dropped, and [extra]/asp is the recommended tool for getting up to date PKGBUILDs via per-package svntogit branches.
Thanks for bringing it to my attention.
I'm assuming that you're familiar with the RPC interface so I don't really know what could be unclear.
I don't use this at all, and I don't want to spend 3 hours researching it, so if you could simply give some examples of URLs you would like to hit and what you would expect to come back, that would be awesome and I can probably work from that. Of course, a patch to the website would be even better.
http://aur.archlinux.org/rpc.php?type=<type>&arg=<arg>
The three types are:
info - accepts pkgnames as arguments, e.g. "...?type=info&arg=foo"
It returns all available information about the package in JSON format.
Example for bauerbill:
{"type":"info","results":{"ID":"33511","Name":"bauerbill","Version":"0.2-1","CategoryID":"16","Description":"A Powerpill extension with AUR and ABS support, among other things.","LocationID":"2","URL":"http:\/\/xyne.archlinux.ca\/info\/bauerbill","URLPath":"\/packages\/bauerbill\/bauerbill.tar.gz","License":"GPL","NumVotes":"110","OutOfDate":"0"}}
For ABS this should be populated with the information available in the ABS tree, which would thus include depends, optdepends, provides, PKGBUILD and local source tarball URL (the same as on the package webpage), etc.
Ideally it would support multiple package names in the URL argument, with some appropriate separator, e.g. "...&arg=foo;bar". I'm not sure which separator would be the best though. In such a case the "results" object in the JSON output would be an array as it is for searches and msearches (see below).
search - searches the available data the same way "pacman -Ss foo" and "pacman -Qs foo" do, e.g. "?type=search&arg=foo"
The information in the output is the same as for info but the "results" object is an array of hits. Example search: "...?type=search&arg=foobar"
{"type":"search","results":[{"ID":"29933","Name":"fooaudio-git","Version":"20090907-1","CategoryID":"12","Description":"Lightweight music player inspired by Foobar2000","LocationID":"2","URL":"http:\/\/blog.matthew.org.pl\/2009\/09\/06\/fooaudio-0-1","URLPath":"\/packages\/fooaudio-git\/fooaudio-git.tar.gz","License":"GPL","NumVotes":"13","OutOfDate":"0"},{"ID":"29650","Name":"mp3gain-foo","Version":"1.5.1.3-2","CategoryID":"12","Description":"mp3gain modified to support id3v2 tags like foobar (replaygain_track_*)","LocationID":"2","URL":"http:\/\/mp3gain.sourceforge.net\/","URLPath":"\/packages\/mp3gain-foo\/mp3gain-foo.tar.gz","License":"LGPL MPL","NumVotes":"2","OutOfDate":"0"}]}
msearch - search by maintainer, e.g. "...&arg=bobo"
The results are in the same format as for "search", but the results are all packages maintained by "bobo" (exact match I think).
The important information is everything that's required for building packages. The idea would be to provide the depends/makedepends/provides/conflicts/etc so that an application can use the interface to determine what needs to be built and in what order. The URL of source tarballs is also necessary.
I could try to look at the website source and create a patch, but it would probably take a while for me to understand, implement and test it as I haven't looked at it before. I was really hoping that it would be easy to adapt the existing AUR RPC code to the ABS tree because most of the code must be there for generating the package web pages.
I appreciate any effort you make towards implementing this. Thanks.
https://www.archlinux.org/packages/core/i686/coreutils/json/
https://www.archlinux.org/packages/core/i686/coreutils/files/json/