1. 08 Jan, 2014 1 commit
  2. 07 Jan, 2014 1 commit
  3. 09 Dec, 2013 1 commit
  4. 05 Dec, 2013 2 commits
  5. 02 Dec, 2013 2 commits
  6. 28 Nov, 2013 2 commits
  7. 13 Nov, 2013 1 commit
  8. 12 Nov, 2013 1 commit
  9. 11 Nov, 2013 1 commit
  10. 01 Nov, 2013 1 commit
    • apt: allow specifying dpkg options · df5fd0e0
      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'
      Yegor Minin committed
  11. 21 Oct, 2013 1 commit
  12. 09 Oct, 2013 2 commits
  13. 28 Sep, 2013 2 commits
    • apt: do not consider not-removed and not-upgraded packages as changes. · 3a8c9f04
      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.
      Blair Zajac committed
    • apt: pass child process stdout and stdout to m.fail_json() and m.exit_json(). · d133c0ae
      Without this, this fails:
      
          - name: apt-get dist-upgrade
            action: apt upgrade=dist
            register: apt_get_contents
      
          - name: apt-get clean
            action: command apt-get clean
            when: apt_get_contents.stdout.find("0 upgraded") == -1
      
      TASK: [apt-get clean] *********************************************************
      
      fatal: [192.168.2.2] => error while evaluating conditional: {% if apt_get_contents.stdout.find("0 upgraded") == -1 %} True {% else %} False {% endif %}
      
      FATAL: all hosts have already failed -- aborting
      Blair Zajac committed
  14. 17 Sep, 2013 1 commit
  15. 12 Sep, 2013 1 commit
  16. 12 Aug, 2013 2 commits
  17. 05 Aug, 2013 1 commit
    • apt: Run remove commands noninteractively · b950f945
      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.
      Alan Grosskurth committed
  18. 22 Jul, 2013 1 commit
  19. 20 Jul, 2013 1 commit
  20. 09 Jul, 2013 1 commit
  21. 30 Jun, 2013 1 commit
  22. 20 Jun, 2013 1 commit
  23. 19 Jun, 2013 4 commits
    • Revert "now modules can implement with_items list globbing w/o updating" · d9c0a5c3
      This reverts commit 4942a06b.
      
      Conflicts:
      
      	lib/ansible/runner/__init__.py
      Michael DeHaan committed
    • Always assume purged for older python-apt · ae421447
      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>
      martin f. krafft committed
    • Introduce non-purged package status · 420f7d7a
      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>
      martin f. krafft committed
    • Fix purging of packages · 8e37a2be
      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>
      martin f. krafft committed
  24. 18 Jun, 2013 1 commit
  25. 15 Jun, 2013 2 commits
  26. 18 May, 2013 1 commit
  27. 17 May, 2013 1 commit
  28. 16 May, 2013 1 commit
  29. 13 May, 2013 1 commit
    • Make package version comparison use globbing. · c7ebe447
      I have something like:
      
        apt: pkg={{ item }} state=present
        with_items:
          - python-pysqlite2=2.6.3-*
          - python-paramiko=1.7.7.1-*
      
      But due to the use of *'s in the version specifications, the apt ansible
      module always reports changed: true. This patch fixes that.
      Jack Kuan committed
  30. 11 May, 2013 1 commit