Ansible Task extension 01-postgis.yaml overwrites the pg_* symlinks in /usr/bin

[Towerful]

Bug report

Describe the bug

Whilst running the playbook against a VM, I was having issues with 27-pg-repack.
One of the issues is that the makefile for pg_repack was trying to target postgres 12, whereas postgres 15 was being installed.
Using ansible pauses, I was able to confirm that pg_config --version was returning the correct version after the setup-postgres.yml tasks.
I added pauses between all the extension installs to see which was causing the issue, and the output of pg_config changed after the 01-postgis.yaml task, where it incorrectly returned postgres 12

I think something in SFCGAL or postgis is overwriting the pg_config file (and perhaps other files) from the symlinks created in setup-postgres.yml. This is then causing pg_repack to target the wrong postgres installation

Expected behavior

the pg_config file (perhaps pg_* files) in /usr/bin should not be overwritten when installing this extension

System information

running the ansible playbook against an Ubuntu20.04 VM with 16 cores

Additional context

Currently, I am duplicating the tasks from the setup-postgres.yml for re-creating the symlinks, and running that after the 01-postgis.yaml task.
Which is a bit of a hack, but I'm not sure how to find what it is in the postgis task that is replacing these files.
Running these addition steps confirms that:
/usr/bin/pgtopo_import, /usr/bin/pgtopo_export, /usr/bin/pg_config, /usr/bin/shp2pgsql, /usr/bin/raster2pgsql, /usr/bin/pgsql2shp
symlinks created during the setup-postgres.yml tasks all get overwritten during the 01-postgis.yaml task, and need to be recreated

[Paul Cioanca]

Hi @Towerful - thanks for reporting this!

We're investigating