[pacman-dev] [RFC] Generation of a .SRCINFO file for source packages

[Dave Reisner]

On Mon, Aug 27, 2012 at 05:08:45PM -0400, canyonknight at 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=packages/boost
>