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.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.
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