[aur-general] Promoting use of .AURINFO

[Dave Reisner]

On Thu, Jan 16, 2014 at 08:52:46PM +0100, Lukas Fleischer wrote:
> 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

Fair enough... I assumed when I mentioned split packages and referenced
Allan's post that it was understood I was going outside of the current
.AURINFO format (which is far too simplistic to be of value in the long
term).

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

Intentional.

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

That shouldn't be the case. What package were you looking at that shows
this in the .AURINFO?  The goal is that pkgbase section provides the
bulk of the metadata -- the individual pkgname sections are only
overrides and supplements. The GetMergedPackage def in the python parser
illustrates how the base and "overlay" create each output package.

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

Because, IMNSHO, this is old fashioned thinking. Everything should be
treated as a split package these days, even if the PKGBUILD only
produces a single package as output. makepkg's code is moving in this
direction as well. It's totally valid to write a PKGBUILD that produces
one package, but has a package_$pkgname() function instead of package().

Since we're going to allow human-massaged .AURINFO files, the AUR's
parser should probably allow pkgname without pkgbase. This should be
simple to handle if you can handle pkgbase + pkgname, as you're
essentially just merging your overrides into the empty set.

> > 
> > 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)?

Yep -- sounds good to me.

Cheers,
Dave