On Thu, Jan 16, 2014 at 11:31 PM, Dave Reisner <[email protected]> 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
