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
