Send patches - preferably formatted by git format-patch - to patches at archlinux32 dot org.
summaryrefslogtreecommitdiff
path: root/scripts/libmakepkg/lint_pkgbuild
AgeCommit message (Collapse)Author
2019-06-06makepkg: restrict pkgname and pkgver to asciiAndrew Gregory
pkgname and pkgver are used as directory names within database files. libarchive does not provide a reliable locale-independent method for reading archive file names, causing errors when archive paths include non-ascii characters. This is a first step toward dealing with FS#49342, by hopefully reducing the number of packages with non-ascii data in the wild before updating libalpm to reject them outright. See https://github.com/libarchive/libarchive/wiki/Filenames and https://github.com/libarchive/libarchive/issues/587 Signed-off-by: Andrew Gregory <andrew.gregory.8@gmail.com> Signed-off-by: Allan McRae <allan@archlinux.org>
2019-05-08scripts: protect against unintended glob matching in [[ ]] RHSEli Schwartz
The right-hand side of the [[ ... = ... ]] keyword is an exception to the general rule that quoting is unnecessary with [[ This is usually not a problem, e.g. in libmakepkg, lint_one_pkgname will already fail if pkgname has an asterisk, but it certainly doesn't hurt to be "more proper" and go with the spec; it is more dangerous in repo-add, which can get caught in an infinite loop instead of safely asserting there is no package named 'foo*'. Reported-by: Rafael Ascensão <rafa.almas@gmail.com> Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2019-01-31libmakepkg: lint disallowed architecture specific variablesmorganamilo
Variables such as 'pkgdesc_x86_64' are invalid, instead of ignoring them raise an error. This also disallows using 'any' as an architecture specific variable Signed-off-by: morganamilo <morganamilo@gmail.com> Signed-off-by: Allan McRae <allan@archlinux.org>
2019-01-31libmakepkg: lint disallowed variables in package()morganamilo
makepkg will now error if disallowed variables are set inside of the package function. Disallowed variables are variables that do exist, like 'makedepends' and 'pkgver' but can not be set inside of a package function. Signed-off-by: morganamilo <morganamilo@gmail.com> Signed-off-by: Allan McRae <allan@archlinux.org>
2019-01-31libmakepkg: centralise random arrays of pkgbuild variablesmorganamilo
Refactor many of the different arrays of pkgbuild variables into scripts/libmakepkg/util/schema.sh.in. Signed-off-by: morganamilo <morganamilo@gmail.com> Signed-off-by: Allan McRae <allan@archlinux.org>
2019-01-22libmakepkg: move checkdepends to the correct arraymorganamilo
Signed-off-by: morganamilo <morganamilo@gmail.com> Signed-off-by: Allan McRae <allan@archlinux.org>
2019-01-22libmakepkg: make gettext replacements more templatedEli Schwartz
Making the undescore be translated is probably not something we need translators to think about. Additionally, a number of places which use the same text differ only by the variable being referenced, so simplifying the string means we can drop a redundant translation. Bonus: we save a few bytes here and there. \o/ Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2019-01-16libmakepkg: disallow using 'any' with other archesmorganamilo
Error if the arch array contains any and any other values. This also fixes a bug where the check for `$arch == 'any'` which only evaluated the first value in the array, meaning the rest of the values would not be linted. Signed-off-by: morganamilo <morganamilo@gmail.com> Signed-off-by: Allan McRae <allan@archlinux.org>
2019-01-14meson: fix regression that broke building libmakepkgEli Schwartz
In commit f7efa6a93d5361af610827d41045d87c7a72f2b5 we added a new file, and also wired it up to the build systems, but it got added under the wrong name in meson.build Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2019-01-10makepkg: check_pkgrel: Don't say "decimal" in the error messageLuke Shumaker
If you have a malformed pkgrel, the error message says that it must be a "decimal". That isn't quite true, as that would mean that `1.1 == 1.10`. Signed-off-by: Allan McRae <allan@archlinux.org>
2019-01-10makepkg: Better error messages for versions in (check, make, ↵Luke Shumaker
opt)depends/provides/conflicts Given the depends depends=('foo>=1.2-1.par2') and the error message ==> ERROR: pkgver in depends is not allowed to contain colons, forward slashes, hyphens or whitespace. One would be lead to believe that the problem is that they gave a pkgrel in depends at all, not that the pkgrel contains letters. Each of the (check,make,opt)depends, conflicts, and provides linters use a glob to trim off properly formed epoch an rel from the full version string, and pass the remainder to check_pkgver(). This does a good job of accepting/rejecting full versions, but doesn't do a good job of generating good error messages when rejecting if it's because of the epoch or rel. 1. Factor out check_epoch() and check_pkgrel() from lint_epoch() and lint_pkgrel(), similarly to check_pkgver(). 2. Add a check_fullpkgver() that takes a full [epoch:]ver[-rel] string and splits it in to epoch/ver/rel, and calls the appropriate check_ function on each. 3. Use check_fullpkgver() in the {,check,make,opt}depends, conflicts, and provides linters. Signed-off-by: Allan McRae <allan@archlinux.org>
2019-01-10libmakepkg/lint_pkgbuild: check for invalid variables even if they're emptyEli Schwartz
Checking the length of the variable to be non-zero before considering it an error is inconsistent; license=() and depends='' and `declare arch` should be considered just as wrong. In fact the current check detects depends='' as non-zero and returns an error, but happily considers the others to be perfectly okay. A more reliable check is to simply see if the name has been declared (whether it is set or not), and then enforce that it's been declared to the right type. As an added benefit, avoiding the creation of proxy-evaled variables to count the number of indexes results in simpler code. Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2018-11-02Add meson.build files to build with mesonDave Reisner
Provide both build systems in parallel for now, to ensure that we work out all the differences between the two. Some time from now, we'll give up on autotools. Meson tends to be faster and probably easier to read/maintain. On my machine, the full meson configure+build+install takes a little under half as long as a similar autotools-based invocation. Building with meson is a two step process. First, configure the build: meson build Then, compile the project: ninja -C build There's some mild differences in functionality between meson and autotools. specifically: 1) No singular update-po target. meson only generates individual update-po targets for each textdomain (of which we have 3). To make this easier, there's a build-aux/update-po script which finds all update-po targets and runs them. 2) No 'make dist' equivalent. Just run 'git archive' to generate a suitable tarball for distribution.
2018-09-19makepkg: lint_pkgver: Run even if PKGVERFUNCLuke Shumaker
lint_pkgver returns 0 if PKGVERFUNC, since it's likely that update_pkgver() will change the value of pkgver anyway, and there's no point in linting the old value. update_pkgver() will call check_pkgver() itself to validate the new value. However, that "optimization" only holds if we're definitely going to call update_pkgver() later; and that's way more complicated than if (( PKGVERFUNC )); then it's more like: if (( !GENINTEG && !PACKAGELIST && !PRINTSRCINFO && !SOURCEONLY && !REPKG && PKGVERFUNC )); then Which is to say: If I have a PKGBUILD with pkgver(): * if I run `makepkg -g` I expect it to lint pkgver, but it won't * if I run `makepkg -R` I expect it to lint pkgver, but it won't * ... So let's fix that. Rather than try to keep a huge list of conditions in sync with the flow of makepkg.sh.in, let's just drop it. As far as I can tell, the only thing that skipping lint_pkgver() really enables is letting the PKGBUILD author write `pkgver=` in the initial version, and letting pkgver() fill it in. They can just start writing `pkgver=0` for that workflow. Signed-off-by: Allan McRae <allan@archlinux.org>
2018-09-19makepkg: reject PKGBUILDs with both split and non-split package functionsEli Schwartz
We accept package_foo() in non-split packages, because it's easier to switch to/from a split package just by removing a pkgname element. But it makes no sense to have both in one PKGBUILD. Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2018-08-10libmakepkg: add pkgbase to linted variablesmorganamilo
Signed-off-by: morganamilo <morganamilo@gmail.com> Signed-off-by: Allan McRae <allan@archlinux.org>
2018-07-27makepkg: reduce strictness of pkgver in depends lintingEli Schwartz
This change was introduced to prevent entries like depends=('foo>'). However, it had the unintended side effect of causing a number of working PKGBUILDs to fail to build. This happened when a PKGBUILD defined one variable through calling a "complex" statement within the PKGBUILD's package function (e.g. a function or evaluating in a subshell), then used it to define the package metadata variable. extract_function_variable() cannot execute the package function in order to retrieve this information, so it performs a simple grep + eval instead and in the process misses the contextual awareness of running within the package function. While not catching these "issues" can result in incorrect SRCINFO, the resulting packages are fine. Stop aborting on the common case where the pkgver of a dependency is dynamically set during the package function until the large number of broken PKGBUILDs are fixed, and the restrictions of the PKGBUILD format are documented. "Fixes" FS#58776 Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2018-07-19libmakepkg: remove accidentally added fileAllan McRae
A blank file slipped into libmakepkg in commit 2c94118d. Signed-off-by: Allan McRae <allan@archlinux.org>
2018-06-18Add missing sha224 sums in man page and lintingmorganamilo
Signed-off-by: morganamilo <morganamilo@gmail.com> Signed-off-by: Allan McRae <allan@archlinux.org>
2018-06-18libmakepkg/lint_pkgbuild: squelch syntax error when a pkgname is emptyEli Schwartz
We fail with an error, but then we also fail with: ==> ERROR: depends is not allowed to be empty. /usr/share/makepkg/lint_pkgbuild/pkgname.sh: line 39: continue: only meaningful in a `for', `while', or `until' loop During the refactor to provide enhanced pkgname=pkgver linting, this was moved out of the ${pkgname[@]} loop to a distinct function, at which time it should have been modified to return rather than continue. Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2018-06-18libmakepkg/lint_pkgbuild: permit versioned optdependsEli Schwartz
pacman accepts these, and there is no good reason to be more restrictive ourselves; we should follow the example of "depends" here. Update the documentation to actually state that this is supported. Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2018-05-12libmakepkg: only save the shellopts we needEli Schwartz
micro-optimization: We only care about temporarily enforcing extglob, so that is the only one we need to explicitly restore. Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2018-05-12libmakepkg/lint_pkgbuild: fix regression in linting ↵Eli Schwartz
depends=(foo=$epoch:$pkgver-$pkgrel) In commit 91b72cc386ca03241791748da5da2b150c724ace support was added for linting depends/etc. to ensure they contain only valid dependency specifiers. However it did not properly take into account the possibility of dependencies linked to a specific pkgrel or epoch, which promptly failed to build because "-" and ":" is not allowed in a pkgver. pkgrel is something supported by pacman and useful for e.g. split packages which cannot be mismatched even if the pkgver is the same. Fix by removing an optional suffixed "-$decimal" when checking for a valid pkgver. epoch is kind of difficult to do without :D so likewise fix by removing an optional prefixed "$integer:" Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2018-04-29libmakepkg/lint_pkgbuild: lint depends/etc. as if they are pkgnameEli Schwartz
depends, provides, conflicts, replaces, and other variables that are meant to contain package names, are now checked to ensure 1) the name component contains only characters that would equate to a valid pkgname. 2) the version component contains only characters that would equate to a valid pkgver. 3) comparison operator is a valid comparison operator (e.g. provides only allows exact = while optdepends doesn't allow anything) This also refactors pkgname into a shared utility function, wires up pkgbase optdepends and provides to use it, and gives pkgver a touchup to allow referencing where it was called from. Fixes FS#57833 and a bit of extra. Signed-off-by: Eli Schwartz <eschwartz@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2018-03-14Update coyrights for 2018Allan McRae
make update-copyright OLD=2017 NEW=201 Signed-off-by: Allan McRae <allan@archlinux.org>
2018-03-14Fix linting of whitespace in pkgverRikard Falkeborn
In order to detect if pkgver contains whitespace, we need to quote it. Previously, only the characters up to the first whitespace was checked. Signed-off-by: Rikard Falkeborn <rikard.falkeborn@gmail.com> Signed-off-by: Allan McRae <allan@archlinux.org>
2017-01-04Update copyright yearsAllan McRae
Signed-off-by: Allan McRae <allan@archlinux.org>
2017-01-04makepkg: Disallow forward slashes in pkgverSteef Hegeman
scripts/libmakepkg/lint_pkgbuild/pkgver.sh.in now raises an error when pkgver contains forward slashes. pkgver containing a forward slash results in a package filename containing a forward slash, which isn't a valid filename. Signed-off-by: Steef Hegeman <steefhegeman@hotmail.com> Signed-off-by: Allan McRae <allan@archlinux.org>
2016-10-10lint_pkgbuild/pkgname: pkgname is not allowed to be emptyChristian Hesse
We checked for empty array elements, but did not catch empty array. Add a check for that case as well. Signed-off-by: Christian Hesse <mail@eworm.de> Signed-off-by: Allan McRae <allan@archlinux.org>
2016-02-20libmakepkg: increase robustness of the detection of array variablesAllan McRae
Extract array detection into its own utility function that ensures extglob is enabled. Suggested-by: Dave Reisner <dreisner@archlinux.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2016-01-25Fix testing of arrays status for arch specific variablesZuyi Hu
Signed-off-by: Allan McRae <allan@archlinux.org>
2016-01-04Update copyright years for 2016Allan McRae
make update-copyright OLD=2015 NEW=2016 Signed-off-by: Allan McRae <allan@archlinux.org>
2015-11-23lint_pkgbuild/variable: increase robustnessAllan McRae
Approach the detection of variables of the wrong type using an approach similar to that used for construction of .SRCINFO files. While doing silly things in bash could still result in false negatives, this approach should be very robust to generatinf false positives results. Signed-off-by: Allan McRae <allan@archlinux.org>
2015-11-23lint_pkgbuild: explicitly return valueAllan McRae
Set the return value to be local and always explictly returns it. Signed-off-by: Allan McRae <allan@archlinux.org>
2015-11-05Refactor lint_source to work with earlier versions of BashAaron Campbell
Negative subscripts to indexed arrays are not supported before 4.2. However, since substring expansion works on arrays, we can specify an offset of -1 to be taken relative to one greater than the maximum index of the specified array (see Parameter Expansion section of the bash man page). This works with both Bash 4.1 and 4.2, and 4.1 is already the oldest supported by pacman. Signed-off-by: Aaron Campbell <aaron@monkey.org> Signed-off-by: Allan McRae <allan@archlinux.org>
2015-10-27libmakepkg: fix pkgver checkingAllan McRae
Signed-off-by: Allan McRae <allan@archlinux.org>
2015-09-22libmakepkg: remove declaration of unused local variablesAllan McRae
Signed-off-by: Allan McRae <allan@archlinux.org>
2015-09-22libmakepkg: return 1 on error in arch arrayAllan McRae
The return value was being assigned when an error was found in a PKGBUILD's arch array but it never was returned. Also remove error message explaining about adding the arch array to a PKGBUILD. That was added a long time ago when the arch array first became compulsory. Signed-off-by: Allan McRae <allan@archlinux.org>
2015-09-07libmakepkg: check if PKGBUILD variables are arrays or not as appropriateAllan McRae
When extracting variables from PKGBUILD (e.g. for .SRCINFO creation) we make assumptions about whether variables are arrays or not. This adds a check to the PKGBUILD linter to ensure variables are arrays or not as appropriate. Signed-off-by: Allan McRae <allan@archlinux.org>
2015-05-16makepkg: put further restrictions on pkgbaseAllan McRae
pkgbase should be subject to the same restrictions as pkgname Signed-off-by: Allan McRae <allan@archlinux.org>
2015-05-16makepkg: merge validate_pkgver into check_pkgverAllan McRae
The check that pkgver is non-empty done in check_pkgver should also be performed after running the pkgver() function. Merge validate_pkgver into check_pkgver and run check_pkgver after updating pkgver. Signed-off-by: Allan McRae <allan@archlinux.org>
2015-05-16libmakepkg: extract PKGBUILD linting functionsAllan McRae
Signed-off-by: Allan McRae <allan@archlinux.org>