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