On 10/27/20 8:25 PM, Morgan Adamiec wrote:
On 28/10/2020 00:04, Allan McRae wrote:
pkgnames/depends/etc where it may be an issue. So I'm not sure this check finds anything in the "break makepkg/pacman" category.
I disagree, it actually does break something, the srcinfio file
Consider the following pkgbuild:
pkgbase=foo pkgname=(a b) pkgver=1 pkgrel=1 arch=(any)
license=(1)
package_a() { license=()
}
package_b() { license=('') }
And the srcinfo file:
pkgbase = foo pkgver = 1 pkgrel = 1 arch = any license = 1
pkgname = a license =
pkgname = b license =
Now package `a` overrides license to an empty array. The srcinfo expresses this by putting an empty license entry.
Now package b defines a license of `empty string`, yet it generates the same output. So it's impossible to tell what the original pkgbuild actually meant.
In both cases, it overrides the license=('1') into non-existence. The question is if "There is no license" or "the license is a zero-length string of emptiness" is semantically meaningful. Especially given the author of the PKGBUILD probably intended to put the former. Given it's a purely display-oriented field, you can absolutely stuff it with whatever you want, and "a zero-length string of emptiness" is not technically invalid even if it is stupid, whereas it's useful to catch makedepends=('') before makepkg -s fails to find a satisfier, root and all.
This example may seen a little contrived, but i assure you it's not. Because stuff like this is done in the wild [1] and as a maintainer of a srcinfo parser it's annoying that it creates this ambiguity.
It remains unclear to me, why the ambiguity matters. -- Eli Schwartz Bug Wrangler and Trusted User