[pacman-dev] [RFC] makepkg: introduce .SRCINFO files for source packages

[Allan McRae]

On 18/10/14 11:59, Dave Reisner wrote:
> Similar to .PKGINFO, .SRCINFO provides structured metadata from the
> PKGBUILD to be included with source packages.
> 
> The format is structured such that it contains a "pkgbase" and one to
> many "pkgname" sections.  Each "pkgname" section represents an "output
> package", and inherits all of the attributes of the "pkgbase" section,
> and then can define their own additive fields.
> 
> For example, a simple PKGBUILD:
> 
>   pkgbase=ponies
>   pkgname=('applejack' 'pinkiepie')
>   pkgver=1.2.3
>   pkgrel=1
>   arch=('x86_64' 'i686')
>   depends=('friendship' 'magic')
> 
>   build() { ...; }
> 
>   package_applejack() {
>     provides=('courage')
> 
>     ...;
>   }
> 
>   package_pinkiepie() {
>     provides=('laughter')
> 
>     ...;
>   }
> 
> Would yield the following .SRCINFO file:
> 
>   pkgbase = ponies
>   	pkgdesc = friendship is magic
>   	pkgver = 1.2.3
>   	pkgrel = 1
>   	arch = x86_64
>   	arch = i686
>   	depends = friendship
>   	depends = magic
> 
>   pkgname = applejack
>   	provides = courage
> 
>   pkgname = pinkiepie
>   	provides = laughter
> 

Having been forced to watch this by my daughter, I still do not
understand the appeal of ponies...

> The code to generate this new file is taken a project which I've been
> incubating[0] under the guise of 'mkaurball', which creates .AURINFO
> files for the AUR. AURINFO is the exactly same file as .SRCINFO, but
> named as such to make it clear that this is specific to the AUR.
> 
> Because we're parsing shell in the packaging functions rather than
> executing it, there *are* some limitations, but these only really crop
> up in more "exotic" PKGBUILDs. Smoketesting[1] for accuracy in the Arch
> repos yields 100% accuracy for [core] and [extra]. [community] clocks in
> at ~98% accuracy (.3% difference per PKGBUILD), largely due to silly
> haskell packages calling pacman from inside the PKGBUILD to determine
> dependencies. 

WTF!

> [multilib] currently shows about 92% accuracy -- a
> statistic which can be largely improved by utilizing the recently merged
> arch-specific attribute work. This is also a smaller repo so the numbers
> are somewhat inflated. In reality, this is only a .8% variance per
> PKGBUILD.

Having not even looked at your patch at this stage...  Do we detect when
this fails?  Could we detect it at the .PKGINFO construction stage and
print a warning?

> Together, we can make PKGBUILD better.
> 
> [0] https://github.com/falconindy/pkgbuild-introspection
> [1] https://github.com/falconindy/pkgbuild-introspection/blob/master/test/smoketest
> ---
> Based on Allan's recent email about the feature freeze being pushed back,
> I'm offering this up for discussion.

This was something that had been flagged as potential for inclusion
anyway.  And I want this in for what I have planned post release...

My usual test PKGBUILD:

PKGBUILD:
pkgname='foobar'
pkgver=1
pkgrel=1
arch=('i686' 'x86_64')
source=('tmp.txt')
source_x86_64+=('foo.bar')
md5sums=('d41d8cd98f00b204e9800998ecf8427e')
md5sums_x86_64=('d41d8cd98f00b204e9800998ecf8427e')

.SRCINFO
# Generated by makepkg 4.1.2-468-gf74e
# Sun Oct 19 11:22:00 UTC 2014
pkgbase = foobar
	pkgver = 1
	pkgrel = 1
	epoch = 0
	arch = i686
	arch = x86_64
	checkdepends =
	makedepends =
	depends =
	optdepends =
	provides =
	conflicts =
	replaces =
	source = tmp.txt
	md5sums = d41d8cd98f00b204e9800998ecf8427e
	source_x86_64 = foo.bar

pkgname = foobar

So there are some bugs:
 - epoch = 0  (should be not printed)
 - Lots of empty values
 - No md5sum_x86_64

Otherwise, all good.  Small query:


> +
> +srcinfo_write_attr() {
> +	# $1: attr name
> +	# $2: attr values
> +
> +	local attrname=$1 attrvalues=("${@:2}")
> +
> +	# normalize whitespace, strip leading and trailing
> +	attrvalues=("${attrvalues[@]//+([[:space:]])/ }")
> +	attrvalues=("${attrvalues[@]#[[:space:]]}")
> +	attrvalues=("${attrvalues[@]%[[:space:]]}")

Make all whitespace a single space then strip whitespace from start and
finish?  What is the first step for?

Allan