[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