On Tue, Dec 10, 2013 at 3:09 PM, Dave Reisner <d@falconindy.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.
This was discussed previously and I don't understand why makepkg -S doesn't include the .PKGINFO file from makepkg (and subsequently the AUR would use that if present instead of the grep system which fails as soon as variables/expansions are involved which is every other package). All the implementation is there.
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 would leave you with a useless "feature" as only a fraction of applicable packages would have the data.
d