On Tue, Jan 14, 2014 at 11:12:17PM +0100, Lukas Fleischer wrote:
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:
Naturally. Having the metadata available is only the first step.
* 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`.
I think you're missing a few steps here. For starters, I don't believe the current .AURINFO parser is capable of consuming the format I'm advertising. Including it without changing the AUR's parser means... Refused uploads? Bad data displayed? It's been suggested a few times in a cousin thread that currently .AURINFO is not widely used. I cloned the AUR to find out how much truth there was to that: 75 out of 56k packages have .AURINFO files (.0001%). So, I think any changes in the AUR to consume a new format should be bothering an inconsequential number of people.
* 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.
With the understanding that not *all* bugs will be fixed in the parser itself. Some PKGBUILDs will simply not be supported. I start to wonder if we really shouldn't just bite the bullet and implement PKGBUILDv2 in pacman. I guess that's a much different conversation, though, and we can already make improvements to data richness in the AUR with this approach. Where the data is sourced from should be a simple implementation detail if it changes in the future.
* 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.
This is just herding cats. mkaurball could eventually become a utility that nags you before running 'makepkg --source' on your behalf. At some point, maybe it goes away.
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