On Mon, Aug 27, 2012 at 05:08:45PM -0400, canyonknight@gmail.com wrote:
Hello all,
I had the idea of adding a .SRCINFO file to source packages generated by makepkg. I did some research to see if this had been previously proposed and where the discussion went. I've collected my thoughts on such an addition for your consideration.
Whoa. Someone who actually did their homework. I'm already excited.
Previous proposal: The idea of generating a .SRCINFO file was previously proposed on the mailing list [1]. No format was ever agreed upon and discussion died off when no fixes were sent based off of developer suggestions. I've included my own proposed format to fuel discussion and maybe reach an ideal format.
Proposed format with example (using "boost" PKGBUILD [2]): - Every variable (pkgver, depends, etc) is preceded by ($pkgname).
I don't like this. Why surround it with parenthesis? pacman in git is already fairly strict about what it allows in pkgname=, so if you're going to advertise this columnar format, I'd say just leave it untouched. (i.e. pkgname="foo bar" won't get past makepkg). The extra characters wrapping the name just makes parsing a little more tedious.
- Every "global" (defined outside a package_* function) variable is explicitly listed for each $pkgname. - Every array (arch, depends, etc) has one line for each array element
I like this, since its consistent with how we do .PKGINFO.
# Generated by makepkg 4.0.3 <snipped example>
As a counter example, what about the following. Similar to how we do the pacman DBs, each package is a "field", e.g. %PACKAGE% pkgname = boost pkgver = 1.50.0 depends = boot-libs=1.50.0 ... %PACKAGE% pkgname = boost-libs pkgver = 1.50.0 depends = icu depends = zlib depends = bzip2 ... Each section is delimited with a blank line, with the field name telling the parser ahead of time what sort of data to expect next.
Advantages of proposed format: - Don't need a bash parser to determine PKGBUILD variables in a source package. This would make things a lot easier for projects (including AUR) that depend on information from PKGBUILD variables. - Previously proposed implementation could run into issues for a package named "global", this proposal avoids need for "global" label.
Disadvantages of proposed format: - Adds additional dot file to every generated source package. - Compared to the previously proposed implementation, this implementation results in more lines (and a bit of redundancy) in each .SRCINFO file due to the avoidance of any "global" variables.
I don't think the redundancy here is a problem. Writing metadata should be dead simple to make reading it back in as equally straight forward.
Thanks for the consideration. I am more than happy to answer any questions relating to anything above.
Regards,
Jason
[1] http://mailman.archlinux.org/pipermail/pacman-dev/2010-August/011461.html [2] https://projects.archlinux.org/svntogit/packages.git/plain/trunk/PKGBUILD?h=...