This was a great idea but is pretty pointless. It's also not being used
by anything and not exposed as a switch on the main class so it would
almost never affect any behaviour.
* Allow any configuration of apt to be done through data bindings by
passing in hashes representing the resources.
* Switch apt::ppa to use `distid` as set in `apt::params. This makes
`apt::ppa` also work for LinuxMint.
Re-introduce proxy support at the class level. Needing to configure a
proxy is such a common scenario that having it on the class is a
reasonable thing. It also affects `apt::ppa`.
Change `apt::ppa` to no longer have its own `proxy` parameter but use
the proxy as configured on the main `apt` class.
Instead of having two additional parameters, `base_name` and
`setting_type` simply parse it from `title`.
We need to prefix most resources with `list-`, `conf-`, or `pref-` any
way to avoid duplicate resources so we might as well leverage that.
This allows you to work around duplicate resource issues when you have
settings of different types with the same name. When the files are built
it is path/${priority}${base_name}${extension}.
This conversion is done by Transpec 3.0.8 with the following command:
transpec spec/classes spec/defines spec/unit
* 87 conversions
from: it { should ... }
to: it { is_expected.to ... }
* 14 conversions
from: obj.should
to: expect(obj).to
* 7 conversions
from: == expected
to: eq(expected)
* 1 conversion
from: it { should_not ... }
to: it { is_expected.not_to ... }
For more details: https://github.com/yujinakayama/transpec#supported-conversions
* Update `release` to default to `$::lsbdistcodename`
* Default `include_src` to false
* Validate more things!
* Stop redefining variables from `apt::params`
This is a 'base' type. It's a simple wrapper around a file which takes
`type`, `ensure`, `content`, `source` and `file_perms`. It is intended
for usage by `apt::conf`, `apt::source` and an upcoming `apt::pref`.
I'm not entirely clear on the history behind this feature, and this
feels sort of hack-y. If you could explain why this is needed that would
be awesome, or if it isn't just merge this :)
* Add support for paramater trusted, valid options are 'true' and false.
defaults to false. True sets the value to trusted=yes.
trusted=yes can be set to indicate that packages from this source are
always authenticated even if the Release file is not signed or the
signature can't be checked.
* Update documentation
- 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
As some places dont have port 11371 open, they are required to use URL as
key_server instead of domain name therefore adding the capability to use URL or
domain name as key_server parameter
In APT preferences files the only allowed comments are lines that start
with `Explanation:`, commented lines that start with a # trigger a
myriad of interesting bugs. This is considered a feature of APT.
Because we're only ever writing a single file at a time with only a #
comment at the top we were getting away with this but it shouldn't be
there in the first place.
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.
Introducing a totally rewritten and tested apt::key. This commit also
patches the spec's of apt::source because it was passing in data that
is no longer allowed by the new validation rules in apt::key.
It does its best to not touch any other specs and where we touch them
only minimally to ensure that we're not introducing breaking changes.
