* package resource: assume a default Homebrew path
Homebrew's `brew` script is installed to /usr/local/bin by default which
is usually not in a non-interactive PATH. We will now first check to see
if `brew` is in PATH, and if not, assume a default of `/usr/local/bin/brew`
Signed-off-by: Adam Leff <adam@leff.co>
* check the proper field for dpkg installation state fixes#2006
Signed-off-by: Mathieu Sauve-Frankel <msf@kisoku.net>
* Properly handle held packages on dpkg-flavored OS
InSpec was looking at the wrong field in `dpkg -s` output to determine
whether a package was installed or not. An installed, held package was
incorrectly reported as uninstalled.
This adds the proper unit tests and also adds a `be_held` matcher.
Thanks to @kisoku for the initial work in #2007.
Signed-off-by: Adam Leff <adam@leff.co>
Many of the resources are named as a top-level class with a fairly generic class name, such as "OS". This causes an issue specifically with kitchen-google which depends on a gem which depends on the "os" gem which itself defines an OS class with a different superclass. This prevents users from using TK, Google Compute, and Inspec without this fix.
Some mocked commands had their digest changed as well due to the new indentation, specifically in the User and RegistryKey classes.
I strongly recommend viewing this diff with `git diff --ignore-space-change`
to see the *real* changes. :)
Package release info (e.g. '19.el7') is often required to determine if
a system has been properly patched.
Lines like the following from rpm are messing up the version returned
by the package resource:
"...\nVersion : 1.8.6p3 Vendor: Red Hat, Inc.\n..."
Correcting this with a new conditional check.
