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.
