# Using yum module to install latest or defined version of a package **URL:** \ **Category:** Ansible Project\ **Created:** [August 21, 2013, 11:27am UTC](https://forum.ansible.com/t/using-yum-module-to-install-latest-or-defined-version-of-a-package/13340 "2013-08-21T11:27:09Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![Byron\_Schlemmer](https://avatars.discourse-cdn.com/v4/letter/b/e95f7d/32.png) [@Byron\_Schlemmer](https://forum.ansible.com/u/Byron_Schlemmer)\ **Post date:** [August 21, 2013, 11:27am UTC](https://forum.ansible.com/t/using-yum-module-to-install-latest-or-defined-version-of-a-package/13340/1 "2013-08-21T11:27:09Z")
Hi all, I’m trying to work out the best way to either install the latest version or a specified version of a package dependent on a group\_vars variable passed. That is, my group\_vars/group contains: mypackage: 1.0 But it could be changed to mypackage: latest And I want package installation to occur accordingly. My play has: - name: install mypackage rpm yum: name=mypackage state=latest when: mypackage\_version == “latest” - name: install mypackage rpm yum: name=mypackage-{{ mypackage\_version }} state=installed when: mypackage\_version != “latest” Now this works but I end up with output from both packages: TASK: [install mypackage rpm] ---
**Author:** ![James\_Cammarata1](https://avatars.discourse-cdn.com/v4/letter/j/d26b3c/32.png) [@James\_Cammarata1](https://forum.ansible.com/u/James_Cammarata1)\ **Post date:** [August 21, 2013, 12:35pm UTC](https://forum.ansible.com/t/using-yum-module-to-install-latest-or-defined-version-of-a-package/13340/2 "2013-08-21T12:35:51Z")
Use state=latest and it will install the latest version. To install a specific version, use name=package-X.Y ---
**Author:** ![Patrick\_Regan](https://avatars.discourse-cdn.com/v4/letter/p/7cd45c/32.png) [@Patrick\_Regan](https://forum.ansible.com/u/Patrick_Regan)\ **Post date:** [August 21, 2013, 12:41pm UTC](https://forum.ansible.com/t/using-yum-module-to-install-latest-or-defined-version-of-a-package/13340/3 "2013-08-21T12:41:20Z")
> Use state=latest and it will install the latest version. To install a > specific version, use name=package-X.Y I think he understands this. If you take a closer look at his play he is using latest if the variable contains latest, and is using `name` when it does not. He's asking if there's a way to keep Ansible from showing the skipped task in the output. ---
**Author:** ![Byron\_Schlemmer](https://avatars.discourse-cdn.com/v4/letter/b/e95f7d/32.png) [@Byron\_Schlemmer](https://forum.ansible.com/u/Byron_Schlemmer)\ **Post date:** [August 21, 2013, 1:58pm UTC](https://forum.ansible.com/t/using-yum-module-to-install-latest-or-defined-version-of-a-package/13340/4 "2013-08-21T13:58:00Z")
Indeed. Or to just run either or dependent on the conditional. I’m basically trying to find out if there is a good way to replicate puppets package resource, eg: package { mypackge: ensure =\> $mypackage\_version; } Where is $mypackage\_version = latest it installs the latest package or 1.0 it installs version 1.0. ---
**Author:** ![James\_Cammarata1](https://avatars.discourse-cdn.com/v4/letter/j/d26b3c/32.png) [@James\_Cammarata1](https://forum.ansible.com/u/James_Cammarata1)\ **Post date:** [August 21, 2013, 4:39pm UTC](https://forum.ansible.com/t/using-yum-module-to-install-latest-or-defined-version-of-a-package/13340/5 "2013-08-21T16:39:29Z")
Sorry about that, that’s what I get for answering questions before my second cup of coffee. I was completely focused on the when: line. Currently, there is no way to suppress skipped messages. ---
**Author:** ![Byron\_Schlemmer](https://avatars.discourse-cdn.com/v4/letter/b/e95f7d/32.png) [@Byron\_Schlemmer](https://forum.ansible.com/u/Byron_Schlemmer)\ **Post date:** [August 21, 2013, 4:54pm UTC](https://forum.ansible.com/t/using-yum-module-to-install-latest-or-defined-version-of-a-package/13340/6 "2013-08-21T16:54:42Z")
Understood. Thanks James. ---
**Author:** ![Michael\_DeHaan2](https://avatars.discourse-cdn.com/v4/letter/m/da6949/32.png) [@Michael\_DeHaan2](https://forum.ansible.com/u/Michael_DeHaan2)\ **Post date:** [August 22, 2013, 2:29am UTC](https://forum.ansible.com/t/using-yum-module-to-install-latest-or-defined-version-of-a-package/13340/7 "2013-08-22T02:29:02Z")
" package { mypackge: ensure =\> $mypackage\_version; } " What James said, yes. you do “name=xyz=1.2.3.4 state=installed” It also supports other operations like “\>” and so on. It should report unchanged here, not skipped. Let me know if you see it reporting skipped. Conditionals like “when:” do report skipped when things are skipped, yes. ---
**Author:** ![Gaston\_Acosta](https://avatars.discourse-cdn.com/v4/letter/g/dc4da7/32.png) [@Gaston\_Acosta](https://forum.ansible.com/u/Gaston_Acosta)\ **Post date:** [October 24, 2014, 1:19pm UTC](https://forum.ansible.com/t/using-yum-module-to-install-latest-or-defined-version-of-a-package/13340/8 "2014-10-24T13:19:05Z")
Hi all, I resolve this using something like this: yum: pkg=httpd-{{ httpd\_version | default(‘_') }} state=latest as the documentation says : "Package name, or package specifier with version, like `name-1.0`. When using state=latest, this can be '_’ which means run: yum -y update. You can also pass a url or a local path to a rpm file." Hope that helps ---
**Author:** ![Dick\_Davies](https://avatars.discourse-cdn.com/v4/letter/d/b9e5f3/32.png) [@Dick\_Davies](https://forum.ansible.com/u/Dick_Davies)\ **Post date:** [October 28, 2014, 12:24pm UTC](https://forum.ansible.com/t/using-yum-module-to-install-latest-or-defined-version-of-a-package/13340/9 "2014-10-28T12:24:22Z")
I just do it with: group\_vars/relevantgroup: httpd\_rpm: httpd # if you aren't fussy - this will get you the latest at the time of the first run # or : httpd\_rpm: http-2.0.36 # if you want a specific version task looks like : - name: install {{ httpd\_rpm }}   yum: name={{ httpd\_rpm }} state=present In my experience, state=latest is probably a Bad Idea in the config management world - packages changing underneath you either a) should reload the service (potentially causing an outage) or b) don't reload the service (almost definitely storing up trouble at next reboot) in both cases there's also the risk that a config file default will change and ruin your day.