apt: upgrade=[safe|full|dist] seems to ignore "default_release" parameter

Archives Ansible Project
1

Hello everybody!

Here’s the thing! I add the Wheezy Backports repo to a newly provisioned VPS and want to do a safe-upgrade before doing anything else. My corresponding lines in the playbook look like this:

  • name: Add Wheezy Backports
    apt_repository: repo=‘deb http://ftp.us.debian.org/debian wheezy-backports main’ state=present update_cache=yes
    tags:

  • init

  • name: Initial safe-upgrade of the system (from wheezy-backports)
    apt: upgrade=safe default_release=wheezy-backports update_cache=yes
    tags:

  • init

Originally run on Ansible 1.5.4. Same on 1.5.5. At this point python-apt, apt-get and aptitude are installed. Playbook is run under root-user.

From where I’m standing, this should translate to “aptitude safe-upgrade -t wheezy-backports”. But it doesn’t seem to include the backports! Or I’m missing something! Same goes for apt: upgrade yes, full, or dist. If I’m ssh’ing to the box and running “aptitude safe-upgrade -t wheezy-backports” I’m getting quite a few upgardable packages…

Thanks in advance!

Cheers
Ralph

2

Anybody able to confirm this pretty please? I also tried:

  • name: Initial safe-upgrade of the system (from wheezy-backports)
    apt: upgrade=safe default_release=wheezy-backports update_cache=yes state=latest

No matter what I keep getting the “OK” (as if there’s nothing to do), whereas the a manual aptitude safe-upgrade -t wheezy-backports gives me 17-ish upgradable packages.

Thanks a ton.
Ralph

3

Really? No one?

I switched to current HEAD, same thing… Would appreciate some comment on this.

Ralph

4

Silence on the mailing list usually means no one has a similar configuration and is able to reproduce what you are seeing.

Here’s the update code if you would like to trace what commands are being called on your end

https://github.com/ansible/ansible/blob/devel/library/packaging/apt#L370

More investigation should be somewhat helpful.

You can check out ansible on a remote machine and use ./hacking/test-module from the checkout to run the module, if you’d like to insert debug code to trace the update function.

5

Thanks for answering Michael.

I took a peek at the code and compared to the signature of the install function (which uses the default_release option), this is not implemented in the upgrade function. So yeah, no check for default_release, no “-t <alternative_repo>”. Should I go ahead and put this on the issue tracker?

6

Yes please, that would be great.

Thanks!