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
signature.asc
Description: OpenPGP digital signature