[aur-general] 'provides' info in AUR

[Jerome Leclanche]

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