Mainline to stable apt repository switch is not managed correctly

[Al-thi]

Hello,

I installed nginx with this ansible role on Debian buster (Debian 10).

I want a stable production environment, and at first I hadn't noticed the ansible variable nginx_branch, which defaults to mainline.

When I noticed the variable, I tried to switch from mainline to stable.

The simple variable change is not enough because the repository line are appended (instead of replacing the existing lines) in the /etc/apt/sources.list.d/nginx.list file :

2023-02-17 18:42:54,155 p=191540 u=xxx n=ansible | changed: [xxx] => (item=deb-src [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] https://nginx.org/packages/debian/ buster nginx)
2023-02-17 18:44:57,657 p=193486 u=xxx n=ansible | included: /home/xxx/code/xxx/external/roles/nginxinc.nginx/tasks/opensource/install-debian.yml for xxx
 deb [arch=amd64 signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] https://nginx.org/packages/mainline/debian/ buster nginx
 deb-src [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] https://nginx.org/packages/mainline/debian/ buster nginx
+deb [arch=amd64 signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] https://nginx.org/packages/debian/ buster nginx
2023-02-17 18:45:01,396 p=193486 u=xxx n=ansible | changed: [xxx] => (item=deb [arch=amd64 signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] https://nginx.org/packages/debian/ buster nginx)
 deb [arch=amd64 signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] https://nginx.org/packages/mainline/debian/ buster nginx
 deb-src [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] https://nginx.org/packages/mainline/debian/ buster nginx
 deb [arch=amd64 signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] https://nginx.org/packages/debian/ buster nginx
+deb-src [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] https://nginx.org/packages/debian/ buster nginx

The repository should IMO be overriding the actual file content in order to correctly switch from mainline to stable (or the other way around).

[alessfg]

I distinctly remember doing some testing around this but I cannot remember whether I could or could not get it working in a painless way. That being said, I'll have another look and if I can't get it working to the standard I'd like I'll at least document somewhere that you might need to uninstall and reinstall NGINX to migrate from mainline to stable.

P.S.: PRs are always more than welcome if you perchance managed to figure out a fix already :)

[Al-thi]

@alessfg why not use a template containing all of the repos, something like this :

{% if nginx_branch = 'mainline' %}
[MAINLINE REPOS LINES]
{% elif nginx_branch = 'stable' %}
[STABLE REPOS LINES]
{% endif %}

That way you won't have to deal with file creation or line deletion and keep idempotency ?

Just thinking out loud, maybe there's something i'm not seeing.

Sadly I don't have time right now to implement this myself, too much work ...
Thank you for your answer.

[alessfg]

I do need to update the apt list of repos in case folks want to then update NGINX without using this role :) -- I use "hard-coded" variables right now (see https://github.com/nginxinc/ansible-role-nginx/blob/main/vars/main.yml#L118-L132) and it works fine under all cases except when downgrading from mainline to stable (stable to mainline results in multiple entries but since mainline has a higher version, it pulls from that one).

[alessfg]

Quick update:
This playbook does correctly downgrade NGINX from mainline to stable, but the next time you upgrade all packages, NGINX will get upgraded to the latest mainline release.

  tasks:
    - name: Install NGINX
      ansible.builtin.include_role:
        name: nginxinc.nginx
      vars:
        nginx_branch: stable
        nginx_version: "{{ version }}"

The fix, like you suggested, would be to override the relevant repository file. That is doable, but it would introduce a potential breaking change if folks are adding extra things to the source file after running the role. The first step, I think, would be to introduce a warning recommending folks do not edit the source file created by the role. After that we can explore what's the best way to override the repository file.