[aur-general] Promoting use of .AURINFO

[Lukas Fleischer]

On Tue, 14 Jan 2014 at 23:54:28, Dave Reisner wrote:
> On Tue, Jan 14, 2014 at 11:12:17PM +0100, Lukas Fleischer wrote:
> [...]
> > * 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?

I didn't read code or test your tool before I wrote the mail, so I
didn't know that you

1) always add a "pkgbase" section (even to non-split packages),

2) indent some lines using tabs and

3) duplicate a lot of stuff in the pkgname section, even if it's
   identical to what is listed in the pkgbase section.

I assumed that the .AURINFO looks as usual for non-split packages and
the pkgbase stuff is just added for split packages. Is there any reason
for having this pkgbase overhead in non-split packages?

> 
> 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.

Existing packages won't be affected by any .AURINFO change anyway (at
least not on the AUR side). That file is only parsed once when
uploading.

> 
> > * 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.

Of course. The good thing is that people can still adjust the meta data
manually if they want, without adding hacks to the PKGBUILD.

> [...]

I just did some tests and the results look pretty good indeed. Do you
plan on creating an Arch package for that (as soon as the controversial
points are addressed)?