[aur-general] Promoting use of .AURINFO

[Jerome Leclanche]

On Fri, Jan 17, 2014 at 9:02 AM, Jerome Leclanche <adys.wh at gmail.com> wrote:
> 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

The alternative is yaml. It would slightly closer to the current
format, however once again you cannot have duplicate keys, you'd have
to use lists. You would also have to use lists instead of sections at
the top level which would look a bit odd.

It would look something like this:

- pkgbase: python34
  python34:
    pkgdesc: Next generation of the python high-level scription language
    depends:
      - expat
      - bzip2
      - gdbm
      - openssl
      - libffi
      - zlib

- pkgname: python34
  python34:
    ...

J. Leclanche