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=5a1137363cb358593a64e0e6d0... [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