Puppet 3.5.0 introduced strict variables and the module handles strict
variables by using the defined() function. This does not work on prior
versions of puppet so we must gate based on that version.
Puppet 4 series has a new setting `strict` that may be set to enforce
strict variables while `strict_variables` remains unset (see PUP-6358)
which causes this conditional to erroniously use non-strict 3.5-era
parsing and fail.
The new conditional corrects the cases such that strict variable
behavior happens on versions 3.5.0 and later.
The unless condition of Exec["add-apt-repository-${name}"] calls test -s, which returns 1 if the file is empty. Because
the file is empty, the unless condition is never true and the repository is added on every execution. This commit
replaces the -s test condition with -f, which is true if the file exists or false otherwise.
Instead of adding every newer release of Ubuntu, let's assume that the
package name that is used today will be used in the future, until the
next change is necessary.
In Ubuntu 15.10 the path of the apt sources file, which is generated by
apt-add-repository, changed to include the distid. This breaks apt::ppa
idempotency, since it does not recognize the repository is already
added.
Reported on puppet-users as well:
https://groups.google.com/forum/#!topic/puppet-users/YzeMyZYUo98
It looks like add-apt-repository changes pluses to underscores when
creating the sources.list.d file. So the name it creates doesn't match
what Puppet expects, and the resource keeps applying on every Puppet
run.
This works around that problem.
The 2.x series added a changed behavior for backport pinning to pin to
origin instead of release. Pinning to release is the correct behavior
for backports though.
* Expose the underlying notify_update setting of the apt::settings resource
This is because not all configuration file changes should trigger an apt::update notification
* apt::pin also shouldn't result in an apt-update call
Adding a pin configuration should apply to the next apt-get update call it shouldn't trigger one itself.
* Added documentation
* Add tests for apt::conf notify_update
NOTE: While out-of-the box support is disabled, it is still possible to
get the same configurations, it will just require explicitly setting the
necessary codename-munging.
This should only affect `apt::ppa`
This adds support for passing in a full pin declaration as the pin
parameter on a source declaration.
It keeps the old behaviour intact, you can still simply do `pin => '10'`
and it will pin on origin with a priority of 10.
Should that not be what you want you can now pass in a full pin
declaration instead. We make no assumptions here, whatever you pass in
will be passed through to pin as-is with the exception of the values for
`ensure` and `before` which are always overridden by us to ensure
everything keeps working as designed.
`apt::ppa` and `apt::setting` don't actually include `apt::update` so
anchors are unnecessary. Move `apt` to use contain instead of anchors,
since it wasn't anchoring properly anyways. Update the tests to make
sure it can have settings and ppas depending on each other without
cycles.
In what universe does it make sense to create a `sources.list.d` entry
for a repository **without** specifying where this repository is?
😖😞😩😧😱
Only when removing the resource should a location not be required.
