2013/12/10 Jerome Leclanche <adys...@gmail.com>: > On Tue, Dec 10, 2013 at 3:16 PM, 郑文辉(Techlive Zheng) > <techlivezh...@gmail.com> wrote: >> 2013/12/10 Dave Reisner <d...@falconindy.com>: >>> 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.blazew...@gmail.com>: >>>> >> > On Tue, Dec 10, 2013 at 2:18 PM, 郑文辉(Techlive Zheng) >>>> >> > <techlivezh...@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 >> 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.