[aur-general] 'provides' info in AUR

[郑文辉(Techlive Zheng)]

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?
> would leave you with a useless "feature" as only a fraction of
> applicable packages would have the data.
>
> d