[aur-general] Promoting use of .AURINFO

[Jerome Leclanche]

On Thu, Jan 16, 2014 at 11:31 PM, Dave Reisner <d at falconindy.com> wrote:
> 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).

Do you have some example .AURINFO files you can post to the list? I've been
dealing with domain-specific packaging a lot the past month and I'm
very interested in a potential solution to all this.


J. Leclanche


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