[aur-dev] pkgbase queries via RPC interface
xyne at archlinux.ca
Fri Aug 15 23:25:12 EDT 2014
On 2014-08-14 23:05 +0200
Lukas Fleischer wrote:
>> B) Add a parameter to query pkgbase data (e.g. object=pkgbase) and return a
>> JSON object with pkgbase-specific data (everything that still applies from
>> regular package data, plus an array of the included packages). Given that
>> there are AUR pages for pkgbases, it would be consistent to provide that
>> data via the RPC interface.
>This sounds better to me.
>> I believe this would be very useful. What do you think? Would it be
>I like this idea. Should not be too hard to implement. Maybe we should
>make the whole thing more flexible by replacing everything with a single
>search method (instead of search, info and multiinfo) with different
>search modes (packages and package bases), a filter to specify the
>fields on is interested in and different query types (by name, by name
That works for me. In that case, the method should accept a list of fields to
search (pkgname, pkgbase, pkgdesc, maintainer, deps, url?, etc.). There should
be a way to search for exact matches (e.g. to retrieve data about a specific
package or package base). That could be done either with regexes (too much
server overhead?) or an extra parameter that forces a perfect match.
The returned objects should include a "type" field to specify what kind of
object they are ("package", "package base").
A filter to reduce the returned fields may be useful in some cases but it's
easy enough to filter on the client-side. I suppose it's a matter of cpu vs
bandwidth for the server.
Search for packages "foo" and "bar" (multiple arguments -> multiple returned
Search for package base "baz":
Search for all packages depending on "foo" (not exact to allow for versioned
You could even split the query string by the "by" parameters to enable
multifield searches, e.g. to search for all python packages maintained by "foo":
There may be multiple arguments to each "by" (e.g.
by=pkgname&arg=python-&arg=python3-) so this may tricky to do with a single
backend pass, but it would be easy with subsequent refining passes for each
I'm not sure what the best way to build in boolean logic would be ("and", "or",
"xor"?, etc.) or if it is even something that you would want to implement.
Maybe with a custom "advanced" parameter that accepts a string that the server
can parse directly (using some existing syntax?).
I'm just kicking around some ideas for the sake of discussion.
More information about the aur-dev