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. J. Leclanche
1) always add a "pkgbase" section (even to non-split packages),
Intentional.
2) indent some lines using tabs and
3) duplicate a lot of stuff in the pkgname section, even if it's identical to what is listed in the pkgbase section.
That shouldn't be the case. What package were you looking at that shows this in the .AURINFO? The goal is that pkgbase section provides the bulk of the metadata -- the individual pkgname sections are only overrides and supplements. The GetMergedPackage def in the python parser illustrates how the base and "overlay" create each output package.
I assumed that the .AURINFO looks as usual for non-split packages and the pkgbase stuff is just added for split packages. Is there any reason for having this pkgbase overhead in non-split packages?
Because, IMNSHO, this is old fashioned thinking. Everything should be treated as a split package these days, even if the PKGBUILD only produces a single package as output. makepkg's code is moving in this direction as well. It's totally valid to write a PKGBUILD that produces one package, but has a package_$pkgname() function instead of package().
Since we're going to allow human-massaged .AURINFO files, the AUR's parser should probably allow pkgname without pkgbase. This should be simple to handle if you can handle pkgbase + pkgname, as you're essentially just merging your overrides into the empty set.
It's been suggested a few times in a cousin thread that currently .AURINFO is not widely used. I cloned the AUR to find out how much truth there was to that: 75 out of 56k packages have .AURINFO files (.0001%). So, I think any changes in the AUR to consume a new format should be bothering an inconsequential number of people.
Existing packages won't be affected by any .AURINFO change anyway (at least not on the AUR side). That file is only parsed once when uploading.
* Add a deprecation warning to the AUR in the upcoming release that is displayed whenever a source tarball without meta data is submitted.
* Fix any remaining bugs that are revealed in production use.
With the understanding that not *all* bugs will be fixed in the parser itself. Some PKGBUILDs will simply not be supported.
Of course. The good thing is that people can still adjust the meta data manually if they want, without adding hacks to the PKGBUILD.
[...]
I just did some tests and the results look pretty good indeed. Do you plan on creating an Arch package for that (as soon as the controversial points are addressed)?
Yep -- sounds good to me.
Cheers, Dave