The status changed should be false if a package state equals to present

[strboul]

trafficstars

yay module doesn't keep track of the packages installed, it re-installs them because of the default behavior of yay (see below for the explanation).

I ran this example playbook on Vagrant.

# test.yml
---
- name: Test
  hosts: all
  gather_facts: true
  tasks:
    - name: Install ntp
      pacman:
        name: extra/ntp
        state: present
      become: true

    - name: Install git
      yay:
        name: extra/git
        state: present

1st run:

ansible-playbook -v -i tests/vagrant/vagrant.inventory playbooks/test.yml

PLAY [Test] ***************************************************************************************************************************************************

TASK [Gathering Facts] ****************************************************************************************************************************************
ok: [192.168.56.2]

TASK [Install ntp] ********************************************************************************************************************************************
changed: [192.168.56.2] => {"changed": true, "msg": "installed 1 package(s). ", "stderr": "", "stderr_lines": [], "stdout": "resolving dependencies.."]}

TASK [Install git] ********************************************************************************************************************************************
changed: [192.168.56.2] => {"changed": true, "msg": "installed 1 package(s). ", "stderr": "", "stderr_lines": [], "stdout": "resolving dependencies.."]}

PLAY RECAP ****************************************************************************************************************************************************
192.168.56.2               : ok=3    changed=2    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Result: 2 changed Expected: 2 changed

2nd run:

ansible-playbook -v -i tests/vagrant/vagrant.inventory playbooks/test.yml

PLAY [Test] ***************************************************************************************************************************************************

TASK [Gathering Facts] ****************************************************************************************************************************************
ok: [192.168.56.2]

TASK [Install ntp] ********************************************************************************************************************************************
ok: [192.168.56.2] => {"changed": false, "msg": "package(s) already installed. "}

TASK [Install git] ********************************************************************************************************************************************
changed: [192.168.56.2] => {"changed": true, "msg": "Installed 1 package(s). "}

PLAY RECAP ****************************************************************************************************************************************************
192.168.56.2               : ok=3    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Result: 1 changed Expected: 0 changed

---

I think the solution is to add the --needed tag to the default install command.

--needed Do not reinstall the targets that are already up-to-date.

https://archlinux.org/pacman/pacman.8.html#_upgrade_options_apply_to_em_s_em_and_em_u_em_a_id_uo_a

$ yay -S extra/git
warning: git-2.35.1-1 is up to date -- reinstalling
resolving dependencies...
looking for conflicting packages...

Packages (1) git-2.35.1-1

Total Installed Size:  33,31 MiB
Net Upgrade Size:       0,00 MiB

:: Proceed with installation? [Y/n] ^C
Interrupt signal received


$ yay -S extra/git --needed
warning: git-2.35.1-1 is up to date -- skipping
 there is nothing to do


$ echo $?
0

[mnussbaum]

The code attempts to check if a package is already installed, and if it's installed and at the most up to date version then it refrains from re-installing the package. This logic is here. I wonder if there's a bug checking the version info? Does anything in the code look incorrect to you?

FWIW in my usage I haven't seen ansible-yay attempt to reinstall up-to-date packages, so I'm curious if there's something about the installation mechanism or package data that's triggering the problem in your case