Ansible: Add support for upgrading packages to package module

Created on 2 May 2017  路  10Comments  路  Source: ansible/ansible

ISSUE TYPE
  • Feature Idea
COMPONENT NAME

package

ANSIBLE VERSION

2.1.2.0

OS / ENVIRONMENT

N/A

SUMMARY

As you know, yum can be used as follows to upgrade all installed packages:

yum: name=* state=latest

That doesn't work for apt for example. That module requires using an upgrade parameter.

If we try to apply the same logic to package module as in yum, we would write something like:

package: name=* state=latest

However this will try to install all packages available in the repository.

What I suggest is to add a parameter to package module that translates into an 'upgrade' for any of the packaging systems it supports.

affects_2.1 affects_2.4 bsd feature hpux module packaging pending_action solaris

Most helpful comment

I got curious about what kind of bizarre package manager does not permit an across-the-board upgrade of all packages. I took this list, and removed those modules which only seemed to add repos and signing keys and such. Here's the result, and it's kind of a mess:

  • name="*" state=latest

    • dnf
    • openbsd_pkg
    • sorcery
    • yum
    • zypper
  • upgrade=yes

    • apk
    • apt
    • homebrew
    • pacman
    • pkgin (but for main packages only, full_upgrade=yes for all packages)
    • xbps
  • update=yes

    • portage
    • swupd
  • no method that I see

    • macports (preview, no core oversight)
    • opkg (preview, no core oversight)
    • pkg5 (preview, no core oversight)
    • pkgng (preview, no core oversight)
    • pkgutil (stable, no core oversight)
    • portinstall (preview, no core oversight)
    • slackpkg (preview, no core oversight)
    • svr4pkg (preview, no core oversight, underlying package manager does not provide an upgrade operation at all)
    • swdepot (preview, no core oversight)
    • urpmi (preview, no core oversight)

I think it is a pity not to include the action "upgrade all installed packages" in the general package manager, especially as it works as long as the different operating systems stay in the same syntax category. But well, I've coded my big case-style multiple if blocks, it's ugly but it works, I just need to avoid looking at it.

All 10 comments

Yes, yes, yes, and thank you @xalvarez

In my testing

package: name=* state=latest

actually works... BUT ONLY IF the underlying package manager is yum! The very same recipe fails badly when executed on a machine where the underlying package manager is apt.

There should absolutely be a way to tell the generic package manager module to upgrade all currently installed packages to the latest version.

I'm not sure a new parameter is needed, it might be simpler to define "*" as a special case so the package module works the same as the yum module. Doing anything on all packages in the repo is useless (remove will destroy the system, install will create conflicts in any big repo, upgrade is impossible since you can't install all), so "*" as an alias for all currently installed packages seems reasonable.

The Alpine "apk" module does not have "name" as a mandatory parameter and accepts the bare-bones

apk:
   upgrade: yes

which could be another option.

Zypper also supports package: name=* state=latest.

I do not believe that this will be implemented (The package module is strictly a least common denominator between the various backend modules that implement it) but I'm cc'ing @bcoca for the official decision.

One could reformulate this as a request for apt and apk to also support the name=* state=latest syntax, which should be possible without breaking existing functionality. In that case the request would work without any changes to the package module.

I'd assume that if that was possible using apt, it would only be natural that it was also possible via package.

Regardless, I think the point of using package is to be able to use fewer conditionals in our play-books so from my point of view it would be very helpful if such a common operation (upgrading packages) was fully supported by _package_.

there are more package management modules: openbsd_pkg, zypper, pacman, opkg, pking, homebrew, portage, pkgng ....

package is the 'lowest common denominator', it is a simple abstraction to all package managers, it is not meant to support every feature or behaviour of each.

In my eyes it would make more sense to add the upgrade option to other package modules (where applicable).

My reasoning for doing this opposed to the way @robinro suggested is that not all distributions support partial upgrades. For those that do, the module can happily support both upgrade (maybe as an alias?) and still allow the current style of yum, zypper etc.

In this case upgrade would serve as the lowest common denominator.

I got curious about what kind of bizarre package manager does not permit an across-the-board upgrade of all packages. I took this list, and removed those modules which only seemed to add repos and signing keys and such. Here's the result, and it's kind of a mess:

  • name="*" state=latest

    • dnf
    • openbsd_pkg
    • sorcery
    • yum
    • zypper
  • upgrade=yes

    • apk
    • apt
    • homebrew
    • pacman
    • pkgin (but for main packages only, full_upgrade=yes for all packages)
    • xbps
  • update=yes

    • portage
    • swupd
  • no method that I see

    • macports (preview, no core oversight)
    • opkg (preview, no core oversight)
    • pkg5 (preview, no core oversight)
    • pkgng (preview, no core oversight)
    • pkgutil (stable, no core oversight)
    • portinstall (preview, no core oversight)
    • slackpkg (preview, no core oversight)
    • svr4pkg (preview, no core oversight, underlying package manager does not provide an upgrade operation at all)
    • swdepot (preview, no core oversight)
    • urpmi (preview, no core oversight)

I think it is a pity not to include the action "upgrade all installed packages" in the general package manager, especially as it works as long as the different operating systems stay in the same syntax category. But well, I've coded my big case-style multiple if blocks, it's ugly but it works, I just need to avoid looking at it.

Feature has been merged to the apt package in devel. Will be in 2.4.

Was this page helpful?
0 / 5 - 0 ratings