Ansible yum module equivalent of rpm -i –force

emmdee asked:

I am trying to make Ansible force install an rpm package to overwrite an existing one.

This works:

- name: RPM force install nodesource and yum clean all
  shell: rpm -i --nosignature --force "https://rpm.nodesource.com/{{ nodejs_rhel_rpm_dir }}/el/{{ ansible_distribution_major_version }}/{{ ansible_architecture }}/nodesource-release-el{{ ansible_distribution_major_version }}-1.noarch.rpm" && yum clean all
  args:
    executable: /bin/bash
  tags:
    - nodejs

I would PREFER to just do it like this, and not use shell module:

- name: Install nodesource npm/node packages
  yum:
    name: "https://rpm.nodesource.com/{{ nodejs_rhel_rpm_dir }}/el/{{ ansible_distribution_major_version }}/{{ ansible_architecture }}/nodesource-release-el{{ ansible_distribution_major_version }}-1.noarch.rpm"
    state: latest
    update_cache: yes
  tags:
    - nodejs

However I cannot seem to force overwrite the existing installed version without using rpm directly. What’s the best method to do this in Ansible without using shell which is against best practice with configuration mgmt.

Am I going to be forced to uninstall & reinstall the package in two steps?

EDIT:

To make this clear, the .rpm being installed is DIFFERENT from the currently installed one.

Currently installed one: https://rpm.nodesource.com/pub_8.x/el/7/x86_64/nodesource-release-el7-1.noarch.rpm

The
NEW one is: https://rpm.nodesource.com/pub_10.x/el/7/x86_64/nodesource-release-el7-1.noarch.rpm

My answer:


The reason this is happening is that the upstream vendor didn’t create the packages with sane version information.

These are nodesource-release RPM files for NodeJS 8.x and 10.x respectively, which install the corresponding yum repository.

I downloaded each of them and looked at their reported information. Both of them had identical name, version and release:

Name        : nodesource-release
Version     : el7
Release     : 1
Architecture: noarch

There is no way for rpm or yum to tell these packages apart. Their metadata make them look identical.

I would first complain to the vendor about this, so that hopefully they will repackage these files to give them some distinguishing characteristics. It would be logical to use the corresponding NodeJS version. In the meantime, I think you’re stuck with your workaround.


View the full question and any other answers on Server Fault.

Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.