[aur-general] 'provides' info in AUR

[Dave Reisner]

On Tue, Dec 10, 2013 at 10:54:42PM +0800, 郑文辉(Techlive Zheng) wrote:
> 2013/12/10 Dave Reisner <d at falconindy.com>:
> > On Tue, Dec 10, 2013 at 10:45:58PM +0800, 郑文辉(Techlive Zheng) wrote:
> >> 2013/12/10 Karol Blazewicz <karol.blazewicz at gmail.com>:
> >> > On Tue, Dec 10, 2013 at 2:18 PM, 郑文辉(Techlive Zheng)
> >> > <techlivezheng at 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
would leave you with a useless "feature" as only a fraction of
applicable packages would have the data.

d