* This keeps us from hitting bugs in repoquery/yum plugins in certain
instances (#2559).
* The previous is also a small performance boost
* Also in is_installed(), when using the yum API, return if we detect
a package name has been installed. We don't need to also check
virtual provides in that case. This is another small performance
boost.
* Sort the list of packages returned by the list parameter.
The yum module allows the 'name' parameter to be given as 'pkg', in
a similar way to some of the other package managers. This change
documents this alias.
The module's 'state' parameter has two other aliases, in line with
the 'apt' action; the 'state' parameter can take 'installed' as an
alias for 'present', and 'removed' as an alias for 'absent'. These
aliases are documented.
Closes#1189.
This will cause the settings in Ansible to override the system settings.
That will have no effect except on systems that have an out-of-Ansible
configuration that disables automatic installation of recommended
packages. Previously, ansible would use the OS default whenever
install_recommends wasn't part of the playbook. This change will cause
the Ansible default configuration setting of installing recommended
packages to override the configuration files set on the OS for things
installed through ansible, even when there is no install_recommends
specified in the playbook. Because the OS default matches the Ansible
default, this shouldn't have wide impact.
This was originally required to allow other methods in SourcesList to
fail, but subsequent changes rendered that unnecessary, and it's just
a cleanup now, and avoids passing in module separately to save().
1. Don't test check_mode in both the caller and in the callee.
2. Don't test HAVE_PYTHON_APT inside an if that tests HAVE_PYTHON_APT
3. Don't be irritatingly vague about why the module fails ("You may be
seeing this because…").
Note that if «apt-get -y install python-apt» succeeds with rc==0, but
for some reason python_apt is not usable afterwards, this will break
because the imports in install_python_apt aren't wrapped inside a
try/except.
In other words, we assume that install_python_apt either succeeds or
fails with a traceback. This commit doesn't affect that behaviour.
