When one accidentally tries to run this module as a user, he gets the error message that python-apt must be installed, no matter what. Because importing apt will trigger an exception as a regular user. Explicitly catching the ImportError will let the exception bubble. The exception clearly says Permission denied somewhere, and the user has a better idea, what he must fix.
The apt module check if a packag eis valid by loking in the cache, checking only for
full name, while it should also check that the name is not just provided.
Fix https://github.com/ansible/ansible/issues/5177
This will allow specifying dpkg options as a string passed over to apt
command. dpkg_options expects a comma-separated string of options to be
passed as dpkg options which will be further expanded. For example
dpkg_options='force-confdef,force-confold' will end up as
-o \"Dpkg::Options::=--force-confold\" when passed to apt
Example usage would be:
-m apt -u ubuntu -s \
-a "upgrade=dist update_cache=yes dpkg_options='force-confold'"
or
apt: upgrade=dist update_cache=yes dpkg_options='force-confold'
If one pins a package and does a 'apt-get dist-upgrade' then the
output looks like:
# apt-get dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
cassandra
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
The check for any changes made should only be on the 'upgraded' and
'newly installed' values and not include the 'to remove' and 'not
upgraded' values.
Packages which are half-installed are not adequately represented by
the .is_installed field of the apt.package.Package object. By using the
lower-level apt_pkg.Package object (which provides the .current_state
field), we can check for a partially-installed state more accurately.
Fixes#3421
I'm seeing ansible hang when trying to remove a package, and the hung
process is `whiptail` like in #2763. It looks like we only use
`APT_ENVVARS` and `DPKG_OPTIONS` for the `apt` commands in install()
and upgrade(). This change uses them in remove() as well, which fixes
the hang.
Older python-apt modules don't export Package.installed_files and there
seems to be no other way to figure out if a package is
removed-but-not-purged, so we just always assume it's purged.
Signed-off-by: martin f. krafft <madduck@madduck.net>
A package may be removed but not purged with APT. The only way to
identify this state is by looking at the list of installed files of
a package. Even if the package has no files installed, this list will be
non-empty until the package is removed:
# python -c "import apt; c=apt.Cache(); c.update(); c.open(); p=c['ruby1.8']; print p, p.installed, p.installed_files"
<Package: name:'ruby1.8' id:1425> None [u'']
# dpkg --purge ruby1.8
(Reading database ... 27904 files and directories currently installed.)
Removing ruby1.8 ...
Purging configuration files for ruby1.8 ...
# python -c "import apt; c=apt.Cache(); c.update(); c.open(); p=c['ruby1.8']; print p, p.installed, p.installed_files"
<Package: name:'ruby1.8' id:1425> None []
See http://bugs.debian.org/712749 too.
If a package is not marked installed but it still 'has_files', then it
should be processed if the request is to purge it.
Signed-off-by: martin f. krafft <madduck@madduck.net>
A small error in the reuse of a variable caused packages to never get
purged. This commit fixes that.
Signed-off-by: martin f. krafft <madduck@madduck.net>
Michael DeHaan