[aur-general] Promoting use of .AURINFO

[Dave Reisner]

On Sun, Jan 12, 2014 at 02:35:33PM +0100, Lukas Fleischer wrote:
> Hi,
> 
> I think we should promote the use of .AURINFO files. Currently, only a
> very small fraction of packages use it. A basic description of its
> format can be found in the commit message of AUR commit 5a11373 [1].
> Regardless of whether we keep that format or use something entirely
> different for metadata later, it is good to have this information stored
> somewhere and the format is simple enough to migrate to another format
> later.
> 
> I think we should at least come up with a tiny tool to generate this
> kind of metadata post-makepkg and put it into the source tarball, then
> add some information to the submission section in the official AUR wiki
> article [2]. Does anyone have plans to write such a tool? Did anyone
> already integrate this functionality into an existing AUR uploader? If
> no one steps up, I might attempt to write one on my own in a couple of
> days.
> 
> I might also add a deprecation warning for source tarballs without
> .AURINFO files in one of the upcoming AUR releases.
> 
> Regards,
> Lukas
> 
> [1] https://projects.archlinux.org/aur.git/commit/?id=5a1137363cb358593a64e0e6d0b0adeb1a9514ff
> [2] https://wiki.archlinux.org/index.php/AUR_User_Guidelines#Submitting_packages

This prompted me to resurrect some old code I had written to do data
extraction from PKGBUILDs. Sadly, I didn't understand my own code and it
quickly proved to be buggy, so I rewrote it from scratch. I think I
mostly understand it now ;). It's well structured, but it's still bash
with a hefty dose of black magic (I don't believe I'm relying on any
undocumented behaviors).

What I have now [1] is some generic shell functions which can extract
metadata from PKGBUILDs. I suspect that it will handle most of what
exists in the official repos. I'm very sure it fails on architecture-
specific overrides, and other bizzare corner cases (e.g. see core/linux).
Since it *does* execute code, it's success rate is rather high. Of
course, you're likely never going to see a 100% solution.

The library includes an output format which I've created based on the
last discussion from pacman-dev; in particular a post from Allan [1].
This can easily be changed if we forsee undesirable shortcomings. I
should note that the format emphasizes split packages as a first class
citizen. My hope is that this can be leveraged to introduce proper
support for split packages in the AUR eventually. I realize that this
probably means work on the AUR side (which I likely won't contribute to)
in order to integrate my solution, but I firmly believe it's worthwhile
if support for split packages is a desirable goal for the AUR (please
tell me it is).

Along with this code, I've created two other utilities:

- parse_aurinfo.py: A parser implementation for the proposed .AURINFO
  format written in python.
- mkaurball: A shell script which creates a source tarball and appends
  the generated .AURINFO file to the tarball.

There's also a debugging utility which simply imports the lib and
dumps an .AURINFO file from a PKGBUILD you point it at.

A nice thing to do next might be to create a test harness which compares
my extracted data to the pacman DBs and look at the precise failure
modes. I know some of the failure modes, but I won't claim to know them
all.

Cheers,
Dave

[1] https://www.github.com/falconindy/pkgbuild_reflection
[2] https://mailman.archlinux.org/pipermail/pacman-dev/2012-August/015910.html