[aur-general] 'provides' info in AUR

[郑文辉(Techlive Zheng)]

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