[aur-general] Promoting use of .AURINFO
d at falconindy.com
Tue Jan 14 13:59:28 EST 2014
On Sun, Jan 12, 2014 at 02:35:33PM +0100, Lukas Fleischer wrote:
> 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 .
> 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
> 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 . 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
> I might also add a deprecation warning for source tarballs without
> .AURINFO files in one of the upcoming AUR releases.
>  https://projects.archlinux.org/aur.git/commit/?id=5a1137363cb358593a64e0e6d0b0adeb1a9514ff
>  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
What I have now  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 .
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
More information about the aur-general