[aur-general] Promoting use of .AURINFO

[Jerome Leclanche]

On Fri, Jan 17, 2014 at 1:52 AM, Dave Reisner <d at falconindy.com> wrote:
> On Thu, Jan 16, 2014 at 11:46:12PM +0000, Jerome Leclanche wrote:
>> 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.
>
> Clone my repo and run './reflect /path/to/PKGBUILD'. If you have an
> ABS tree cloned into /var/abs, you can just run './reflect $repo/$pkg'.
>

I should have said: do you have some exotic examples of packages that
showcase the full functionality :)

If you're going to change the format, may I advise going with the
ini/conf format? It's very simple to implement, and in python it's
already handled by the configparser module.
It would require one change: duplicate keys result in undefined
behaviour. I would recommend going with the same "list" syntax that
xdg defines for its ini files: list values are separated by a
semicolon.
So it could look something like this:

[pkgbase python34]
pkgdesc = Next generation of the python high-level scription language
pkgver = 3.4.0b2
pkgrel = 1
url = http://www.python.org/
makedepends = tk;sqlite;valgrind
depends = expat;bzip2;gdbm;openssl;libffi;zlib
optdepends = "tk: for tkinter";sqlite

[pkgname python34]
pkgdesc = Next generation of the python high-level scription language
url = http://www.python.org/
license = custom
depends = expat;bzip2;gdbm;openssl;libffi;zlib
optdepends = "tk: for tkinter";sqlite

J. Leclanche