[aur-dev] Making the AUR package list more useful

[Xyne]

Lukas Fleischer wrote:

>I am not in favor of adding regular expressions on the server side. I
>mentioned some of the reasons in an earlier reply and you agreed.
>However, instead of saying that we need something less powerful (like
>prefix and suffix matching) on the server side, I think that adding
>support for regular expressions (and maybe even more powerful things) on
>the client side is the way to go.
>
>Lukas

Hi ho,

I'm nearing the end of a big rewrite of powerpill/bauerbill that provides a
completely generic interface for extending existing binary repos with build
support as well as adding build-only repos such as the AUR. While working on
interfaces to generalize Pacman's various sync functionality (-Ss, -Si, -Sg,
-Sp, etc.) I have had to provided reduced information for operations that query
the full list of packages in the AUR due to limitations of the pkglist (e.g. no
versions in -Sl). I have also had to cobble together lazy lookups to get all
necessary build information given that the current AUR RPC interface does not
provide all fields in the SRCINFO (when I last checked).

Having access to a full offline database of SRCINFO would be *very* useful,
especially if it can be downloaded incrementally (e.g. with zsync as
suggested). Providing the SRCINFO directly without any additional formatting
provides a de-facto (official?) standard that is reliable and directly tied to
pacman/makepkg. AUR-specific information could be added to a second file
(either in JSON format or one that follows SRCINFO). Besides the AUR ID/URL,
votes, etc, you could also include the hash of the commit that was used to
generate the database entry. This would prevent errors due to the package on
the server leading the package in the downloaded database.

How big would such a database be? How much overhead is involved? How much
overhead would the zsync operation introduce when people begin to regularly
query updates?

Regards,
Xyne