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
