On Tue, Dec 10, 2013 at 3:16 PM, 郑文辉(Techlive Zheng) <[email protected]> wrote: > 2013/12/10 Dave Reisner <[email protected]>: >> On Tue, Dec 10, 2013 at 10:54:42PM +0800, 郑文辉(Techlive Zheng) wrote: >>> 2013/12/10 Dave Reisner <[email protected]>: >>> > On Tue, Dec 10, 2013 at 10:45:58PM +0800, 郑文辉(Techlive Zheng) wrote: >>> >> 2013/12/10 Karol Blazewicz <[email protected]>: >>> >> > On Tue, Dec 10, 2013 at 2:18 PM, 郑文辉(Techlive Zheng) >>> >> > <[email protected]> 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 > 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. >> >> d
