- 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
when updating or installing newer packages with apt::force and you have changed previous
configuration files aptitude or apt-get will prompt what to do. You can suppress that
by pre-define the action with cfg_files parameter (new, old or unchanged and its backward
compatible if not defined). With a second optional parameter cfg_missing you can force
your provider to install missing configuration files as well.
Signed-off-by: Martin Seener <martin@seener.de>
apt::force: Changed selectors used in force.pp to case statements; refs #module-1306
Signed-off-by: Martin Seener <martin@seener.de>
apt::force: rspec: fixed the failing tests and added validate_re for cfg_files and validate_bool for cfg_missing. Also removed default values for both case statements and only allow pre-defined values or true/false. Furthermore enhanced the README refs #module-1306
Was able to fix the failing rspec tests for the patch.
Thanks to Morgan Haskel.
Signed-off-by: Martin Seener <martin@seener.de>
Despite the puppetlabs-stdlib documentation says validation_re supports 3 arguments the tests failed telling that only 2 are supported. Fixed this by removing the 3 optional argument; refs #modules-1306
Signed-off-by: Martin Seener <martin.seener@barzahlen.de>
apt::force: updated readme refs #module-1306
Signed-off-by: Martin Seener <martin@seener.de>
fix for default debian installations
all files in /etc/apt/preferences without _ will be silently ignore according to debian manpage. Addionally its not a good idea to write versionnumber in filename cause there is no way to delete this files if you increase versionumber
Update source_spec.rb
add a way to include debsrc only (useful for debian/ubuntu build server ... jenkins ect)
Update source_spec.rb
var rename
Update source.list.erb
add include_deb "switch"
Update source.pp
"include_deb" defaultvalue = true
Update hold_spec.rb
change the name of the preferences file (hold)
Update source_spec.rb
Update README.md
Doku: 'include_deb' included next to 'include_src' in examples
Update README.md
typo
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.
Ubuntu 14.04 ships with apt 0.9.15, has a ``fancy progress bar'', which
is a green bar that shows at the bottom of the terminal showing progress
throughout install.
This patch enables the progress bar, which is usually done by running
echo 'Dpkg::Progress-Fancy "1";' > /etc/apt/apt.conf.d/99progressbar
The module used to always pin backports to a priority of 200. This
default is still retained but is now configurable.
Additionally the default is now an Integer, not a 'quoted Integer' and
the tests have been updated to reflect this. This matters for future
parser as it will now kick people if they pass in a stringified integer
as priority.
I am aware this can be done with `dpkg --set-selections`, `apt-mark`
or `ensure => 'held'` on a package resource. The changes to the README
include the full rationale for wanting another mechanism.
Instead of perpetuating the use of parameterized classes, which we do
not want to do in light of Puppet v3 with Hiera integration, this change
invites people to use 'include' instead of the parameterized class
syntax when no params are present.
*Note: I thought this was small enough to forgo a TOC. Please let me
know if one is desired and I can add it in.*
Before alterations, this content was the module author- determined
description of and instructions for use of the module.
As part of a joint Forge/Docs team effort to standardize formatting and
encourage quality module documentation, a best practices README
template was created via internal and external user testing. That
template was then applied to this module.
I pulled in content from the original README on GitHub. Standard
headings were added (Overview, Module Description, Setup, Usage,
Implementation, etc.) to organize content, existent content was moved
under its appropriate heading and edited for tone/flow/clarity, and
basic formatting was done to adhere to template standards.
Prior to this commit, the only information about the Puppet Labs
repository source was in the tests folder.
This commit adds example usage for apt::source to the README for
the Puppet Labs APT repository.
Prior to this commit, this modules README had no list of contributors.
This commit adds such a list and corrects a typo I overlooked on the
last pull request.
Adding this defined type allows puppet to add keys to the apt keystore without
needing to add a corresponding source; it also adds the "key_source" parameter
for wget'ing keys from arbitrary URLs, and allows for keys to be explicity
removed.
apt::key allows a key to be ensured present multiple times to account for
apt::source resources that all reference the same key. However, this means
that it is possible for a given key to be defined multiple times with
differing source parameters. e.g.
apt::key { "Add key: 4BD6EC30 from Apt::Source bunny":
key => "4BD6EC30",
key_server => "pgp.mit.edu",
}
apt::key { "Add key: 4BD6EC30 from Apt::Source rabbit":
key => "4BD6EC30",
key_server => "keyserver.ubuntu.com",
}
The defined type will accept both definitions and will create multiple exec
resources. This was deemed preferable to the alternative (creating only one
exec resource) in that one broken definition won't hose an entire catalog. If
one definition fails to install the key because of a bad "key_server", the
next apt::key that uses the key will get it done.
