[aur-general] Promoting use of .AURINFO

[Dave Reisner]

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