[aur-dev] AUR 2.1.0 released

kachelaqa kachelaqa at gmail.com
Mon Mar 18 17:25:42 EDT 2013

On 18/03/13 20:48, Lukas Fleischer wrote:
> On Mon, Mar 18, 2013 at 08:41:37PM +0000, kachelaqa wrote:
>> On 18/03/13 19:18, Lukas Fleischer wrote:
>>> Changes since 2.0.1:
>>> * pkgsubmit.php: Parse .AURINFO metadata.
>>> .AURINFO files can now be included in source packages to overwrite
>>> specific PKGBUILD fields. .AURINFO files are parsed line by line. The
>>> syntax for each line is "key = value", where key is any of the following
>>> field names:
>>> * pkgname
>>> * pkgver
>>> * pkgdesc
>>> * url
>>> * license
>>> * depend
>>> Multiple "depend" lines can be specified to add multiple dependencies.
>> I've read a couple of threads [1][2] relating to this topic, and I
>> am puzzled by the idea of using .AURINFO files to "overwrite"
>> PKGBUILD fields. What is the use case for this? It seems completely
>> different to the idea behind .SRCINFO files. Have there been some
>> other discussions on this topic that I've missed?
> Why is it completely different? .AURINFO files are .SRCINFO files
> without support for split packages (which we currently do not support in
> the AUR anyway).
> The use cases are pretty obvious: The AUR does not include a full bash
> parser and will never include one -- metadata should be provided by the
> client instead.
>> [1] https://mailman.archlinux.org/pipermail/pacman-dev/2012-August/015900.html
>> [2] https://mailman.archlinux.org/pipermail/aur-dev/2013-March/002392.html

I think I was thrown by the word "overwrite", which seems to suggest 
providing alternative values to the ones in the PKGBUILD - whereas the 
real purpose is to simply offer a "preferred" source for the same values 
(i.e. one which is easier to parse).

The restriction on the available fields also seemed a little puzzling to 
me - but I suppose package maintainers are free to include whatever 
fields they like (as long as they follow the general file format).

Will the inclusion of an .AURINFO file be a requirement at some stage in 
the future?

More information about the aur-dev mailing list