[aur-dev] AUR 2.1.0 released

[Lukas Fleischer]

On Mon, Mar 18, 2013 at 09:25:42PM +0000, kachelaqa wrote:
> 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).

It is used as an alternate source if you specify all fields. The idea is
that you can overwrite fields that the AUR PKGBUILD parser fails to
parse without having to update other fields like the package version on
every update. This might be changed in the future.

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

Which ones are missing? I don't think that the AUR uses any other
fields.

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

This might become a requirement if it is implemented in makepkg or some
other tool that auto-generates such files. It is just an experimental
feature for now.