* apt: If the cache object fails to lost due to a corrupt file, try to update the cache until it is fixed.
* Append -q to the update parameters
* Remove unused variable
* Use a string that doesn't rely on internationalization
* Use py24 exception style
* Use get_exception
Fixes#2951
builddep only requires a source package to be in the repos but our code
was checking for a binary package before running buiddep. Reversing the
order makes it work correctly.
Fixes#4519
This change is in response to issue #1497 where the apt module would not properly updating the apt cache in some situations and never returned a state change on cache update when the module was used without or without an item to be installed or upgraded.
The change simply allows the apt module to update the cache when update_cache option is used without or without a set cache_valid_time.
If cache_valid_time is set and the on disk mtime for apt cache is ">" the provided amount of seconds, which now has a default of 0, the apt cache will be updated. Additionally if no upgrade, package, or deb is installed or changed but the apt cache is updated the module will return a changed state which will help users to know that the state of the environment has changed due to a task operation, even if it was only an apt cache update.
fixes#1497
Signed-off-by: Kevin Carter <kevin.carter@rackspace.com>
- Use range instead of xrange.
- Use python3-apt package for python 3.
- Eliminate unsupported for/else/raise usage.
- Use list on dict.items when modifying dict.
- Update requirements documentation.
Also made non-intrustive style fixes (adding blank lines).
Fix KeyError: 'prepared' while installing dependencies using deb=<file>.deb
This error shows up when --diff was not passed by and the deb files has dependencies not yet installed.
Closes#3752.
for install, remove, deb_install, and upgrade.
Since apt has very commonly familiar output, just use the normal output
from apt-get or aptitude -- trimmed to the interesting parts -- to show
to the user if she specified --diff on the CLI.
Uses the recent support for the `diff['prepared]` key.
Fixesansible/ansible#10239
This is useful for packages that bootstrap their own apt-key setup - only
the initial installation will require overriding. Notable examples are the
Dropbox and Google Chrome packages.
(Setting force=yes is far too strong: I only want to bypass
authentication!)
Signed-off-by: Chris Lamb <chris@chris-lamb.co.uk>
This mirrors a nearly identical change made to apt_repository.py.
Also removes the use of apt-get --force-yes as it can be dangerous
and should not be necessary (apt_repository.py does not use it).
Repeating the explanation from the apt_respository change below:
Since use_unsafe_shell is suspicious from a security point
of view (or it wouldn't be unsafe), the less we have, the less
code we have to thoroughly inspect for a security audit.
In this case, the '&&' can be replaced by doing 2 calls to run_command.
The old method left settings in the environment. The new method takes
care of clearing them after use. In this module, the old method was
also setting the environment too late to affect all the command line
tools which lead to a bug.
Fixes https://github.com/ansible/ansible/issues/14264
Without this change, some trouble may occur when "deb" parameter
is used as env vars controlling dpkg are not set. For example,
installing a package that requires user input will never end since
DEBIAN_FRONTEND=noninteractive is not set.
So export env vars in APT_ENV_VARS before run dpkg, like in cases
using apt-get/aptitude.
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.
