2013/12/10 Jerome Leclanche <adys.wh@gmail.com>:
On Tue, Dec 10, 2013 at 3:16 PM, 郑文辉(Techlive Zheng) <techlivezheng@gmail.com> wrote:
On Tue, Dec 10, 2013 at 10:54:42PM +0800, 郑文辉(Techlive Zheng) wrote:
2013/12/10 Dave Reisner <d@falconindy.com>:
On Tue, Dec 10, 2013 at 10:45:58PM +0800, 郑文辉(Techlive Zheng) wrote:
2013/12/10 Karol Blazewicz <karol.blazewicz@gmail.com>: > On Tue, Dec 10, 2013 at 2:18 PM, 郑文辉(Techlive Zheng) > <techlivezheng@gmail.com> wrote: >> Hey, I wonder if it is possible to query the `provides` of a package in AUR? > > Is e.g. 'cower -ii wine-git' good enough?
Acctually, I want to know if it is possible to query the AUR through API to know what packages provide the desired package. e.g. I query for packages provived 'wine', and get I get 'wine-git' and others. Does cower do that?
No, cower doesn't do this because the AUR's RPC interface doesn't do this.
Okay, understand, so that's a todo, I guess.
Well, sure... but I suspect this will never make it into the AUR, given the current implementation of a lot of things. For a universal solution, you'd need to:
1) Extend the PKGBUILD parser to parse provides. This alone is problematic since people insist on dumping split packages on the AUR. There's also plenty of reasons not to extend the PKGBUILD parser in its current form. 2) Extend the DB schema to store and relate the newly parsed provides. 3) Extend RPC responses to include the provides in info/search responses. 4) Add a flag to the search API to allow searching by providers (because this shouldn't be the default behavior, lest you break existing tools). 5) Reparse every single package in the AUR so that steps 1-4 are actually meaningful.
The half-assed solution would be to draw provides data from .AURINFO, but then you rely on submitters to do the right thing. Inevitably, this How about change `makepkg --source` to let it generate a PHP-parsing friendly
2013/12/10 Dave Reisner <d@falconindy.com>: format like the `ini` format in the final src tarball, doss this solves everything?
That's exactly what .PKGINFO files are and it's imho the only sane way to do this. Problem are, they're not generated by -S.
would leave you with a useless "feature" as only a fraction of applicable packages would have the data.
That shold be an easy fix, I guess, someone just need to acctually submit the patch and discuss it with Allan.