Also more test cases are added for the symlink rule.

The symlink rule currently complains about these even if
the target file exists.

Dan McGee authored Mar 15, 2011 and Rémy Oudompheng committed Mar 19, 2011

Add an additional fake package variable '%SETVARS%' that shows the
currently defined variables when processing a PKGBUILD. Use this list in
the extravars rule instead of broke-ass regex parsing that will never
catch every possible corner case.

Also update the tests accordingly. Variables defined inside a function
are nothing we are going to worry about at the moment, so safely ignore
them. Add a legal variable to ensure we don't have any false positives,
and fix our own misgivings in the PKGBUILD parser so we aren't polluting
the namespace.

Signed-off-by: Dan McGee <dan@archlinux.org>
Signed-off-by: Rémy Oudompheng <remy@archlinux.org>

Dan McGee authored Mar 15, 2011 and Rémy Oudompheng committed Mar 19, 2011

This reverts the non-test portions of commit
e2044d45

.

This is not the proper way to fix this, and we most definitely should
not have to parse, subprocess, or do anything with bash more than once,
especially in a rule. We also shouldn't assume everyone has a perfectly
clean environment with no extra variables exported and defined. Revert
the entire thing, minus the added test, with a better fix on the way.

Signed-off-by: Dan McGee <dan@archlinux.org>
Signed-off-by: Rémy Oudompheng <remy@archlinux.org>

A typical case is an array of unquoted, versioned dependencies
which spans over several lines. False positives may still appear
in the case of multiline string literals containing the '=' sign.

ldconfig would be run with the current user's locale, outputting
non ASCII characters.

This fixes bugs FS#23259 and FS#23260.

Dan McGee authored Feb 27, 2011 and Rémy Oudompheng committed Mar 04, 2011

We regressed when splitting the package parser into two scripts; add a
variable to configure the path it is found on and add a 'namcap-devel'
script that allows running the whole deal from the current git checkout.

Signed-off-by: Dan McGee <dan@archlinux.org>

Dan McGee authored Feb 27, 2011 and Rémy Oudompheng committed Mar 04, 2011

A lot clearer and not magical.

Signed-off-by: Dan McGee <dan@archlinux.org>

Dan McGee authored Feb 27, 2011 and Rémy Oudompheng committed Mar 04, 2011

And additionally, don't swallow error output from parsepkgbuild calls-
this helped debug the next issue with a patch to come.

Signed-off-by: Dan McGee <dan@archlinux.org>

The kdeprograms and splitpkgbuild checks that certain dependencies are
correctly specified in the PKGBUILD. Sometimes these could be
actually available via a dependency chain and a naïve scan
would not notice it.

Using the getcovered function in Namcap.depends these indirect links are
spotted.

Two new rules are implemented:
- a check for the existence of all package() functions:
  the main work is actually done in parsepkgbuild
- a check for missing makedepends w.r.t. individual depends
  of children packages. For the moment no smart lookup of
  dependencies is done.

Requested by Pierre Schmitz.

Rules derived from PkgbuildRule receive the parent pkginfo
object and should treat the children is needed, whereas
PkgInfoRule's receive the children pkginfo individually.

Previously the rule list was obtained using an obscure
'-r list' option.