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

[Ralph]

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

[Ralph]

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

[Ralph]

Really? No one?

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

Ralph

Am Mittwoch, 23. April 2014 11:37:55 UTC+2 schrieb Ralph:

[Michael DeHaan]

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.

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/56f67b66-266b-4306-a8a8-3c372f985651%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Ralph]

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?

[Michael DeHaan]

Yes please, that would be great.

Thanks!

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/06082c25-b06e-46c6-9ab7-023e9f1d66b3%40googlegroups.com.