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