On Tue, 14 Jan 2014 at 19:59:28, Dave Reisner wrote:
[...] 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.
Awesome! I will give it a try soon. Split packages are definitely a desirable goal for the AUR but that feature requires a lot of work on the AUR side indeed. I won't be able to do much AUR coding until April or May, so what I suggest is the following strategy: * Test your utility. Do some manual tests and automated tests you described below. Fix common use cases. * Create a package that contains mkaurball and put that in [extra] or [community]. Update all Wiki articles etc., replacing `makepkg --source` with `mkaurball`. * Add a deprecation warning to the AUR in the upcoming release that is displayed whenever a source tarball without meta data is submitted. * Fix any remaining bugs that are revealed in production use. * Add support for split packages in the next major release. At the same time, try to integrate .SRCINFO support into makepkg (and support both .AURINFO and .SRCINFO in the AUR, deprecating .AURINFO). That way, the format and the meta data generator gets a lot of testing. The only downside of this approach is that users temporarily need to switch to `mkaurball` and (probably) switch back to `makepkg --source` later.
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