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

Allan McRae allan at archlinux.org
Mon Aug 27 23:23:49 EDT 2012


On 28/08/12 07:08, 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.
> 
> 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.

I am composing this offline so have not gone back through the old
posts...  but I thought the main issue was that the split package
variables are not defined until running the package_* functions.  I.e.
we do not know the values of any overridden values unless we actually
build the package.

This is the main issue that needs solved.


> Proposed format with example (using "boost" PKGBUILD [2]):
> - Every variable (pkgver, depends, etc) is preceded by ($pkgname).
> - 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
> 

<snip>
So much duplication!  How about just:

pkgbase = boost
... (all global values) ...

pkgname = boost
... (overrides for boost) ...

pkgname = boost-libs
... (overrides for boost-libs) ...


> 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.

But you do if you need to extract the values without running a full build.


> Disadvantages of proposed format:
> - Adds additional dot file to every generated source package.

No need to worry about that.


Allan


More information about the pacman-dev mailing list