The /usr/lib/update-notifier/apt-check script returns its output
to STDERR but a recent change to the script redirects STDERR to
/dev/null. This will cause the array to always be empty.
Combined with that problem, while we were checking for the result
being nil, we never checked for an invalid array. As a result,
the apt_has_updates was always true and the apt_updates and
apt_security_updates facts were trying to read from an empty array
and failing.
- fix spec tests to include osfamily fact
- add spec tests to verify current default behavior unimpacted.
- manage the update-stamp file in puppet via content rather than a served file.
- update custom fact to return -1 if the file doesn't exist
- add spec test for custom fact
- refactor to use a variable vs a collector/override
- document parameters a bit more verbosely
- remove empty unconstrained fact
- Add osfamily fact to backports tests to facilitate functional tests on non-debian hosts
Making use of the apt-check command from the 'update-notifier-common'
package (if available) display the number of available updates, number of
security updates as well as the update package names.
For some reason, even though our own tests pass with `require
puppet_x/apt_key/patch_openuri` every other module that depends on
puppetlabs-apt is now breaking in tests claiming it can't load that
module.
Somewhere along the way something is probably messing with LOADPATH
causing this to trip up. This should fix the issues for everyone.
This commit affects:
* puppetlabs/puppetlabs-apt#229
* puppetlabs/puppetlabs-postgresql#391
This commits introduces:
* The apt_key type;
* The apt_key provider;
* Unit tests for the type;
* Beaker/acceptance tests for the type/provider.
The idea behind apt_key is that apt::key will simply become a wrapper
that uses apt_key. Being a native type/provider apt_key is a lot less
error prone than the current exec behaviour of apt::key and adds a few
nice bonuses like inventory capabilities for mcollective users.
