CI recently started failing `conf`-package lower bound tests

[jmid]

These past few days I am starting to see a number of failures caused by exploring conf-package lower bounds:

• the conf-gmp.1 issue from mark conf-gmp.1 as avoid version #28540 also showed up in packages for release 1.8.2 of why3 #28511, Add jasmin.2025.06.1 #28526, and Update Claudius to 1.2.1 #28530
• the latest run in packages for release 1.8.2 of why3 #28511 also reveals a cursed lower-bound interaction of conf-llvm.17 and conf-libclang.12
• downgrading conf-gmp-powm-sec.1 is causing failures in Package proton.1.0.16 #28539 that didn't show up 5 days ago in Package proton.1.0.15 #28518 https://opam.ci.ocaml.org/github/ocaml/opam-repository/commit/95f3a515f3bb22620685d715b44c91260a53266c

So it appears that something has changed, causing these to now surface and I am curious to understand what triggered it... 🤔

Originally posted by @jmid in #28540 (comment)

[jmid]

OK, comparing
https://opam.ci.ocaml.org/github/ocaml/opam-repository/commit/95f3a515f3bb22620685d715b44c91260a53266c/variant/compilers,4.14,proton.1.0.15,lower-bounds
https://opam.ci.ocaml.org/github/ocaml/opam-repository/commit/838b60f55ba5673b90bb32ff755274fcd893caca/variant/compilers,4.14,proton.1.0.16,lower-bounds
I see both of runs exploring lower bounds for conf packages, e.g., for the former

  - downgrade conf-gmp              5 to 1                    [required by zarith]
  - downgrade conf-gmp-powm-sec     4 to 1                    [uses conf-gmp]
  - downgrade conf-pkg-config       4 to 1.0                  [required by ctypes]
  - downgrade conf-zstd             1.3.8 to 0.1 (deprecated) [uses conf-pkg-config]

and for the latter:

  - downgrade conf-gmp          5 to 4                    [required by proton]
  - downgrade conf-gmp-powm-sec 4 to 1                    [uses conf-gmp]
  - downgrade conf-pkg-config   4 to 1.0                  [required by ctypes]
  - downgrade conf-zstd         1.3.8 to 0.1 (deprecated) [uses conf-pkg-config]

A notable difference is however the runner used:

• The 1.0.15 run used debian-12-ocaml-4.14/amd64 whereas
• the 1.0.16 run used debian-13-ocaml-4.14/amd64

On https://pkgs.org/search/?q=gcc I can see

• debian-12 uses gcc_12.2.0-3 whereas
• debian-13 uses gcc_14.2.0-1

so I believe the mystery is solved with https://gcc.gnu.org/gcc-14/porting_to.html

To address this I guess we will need to add avoid constraints to selected conf-packages, like @raphael-proust already started in #28540

[raphael-proust]

In #28540 I went for avoid-version. It's a blunt solution.

The proper solution would be to have a conf-gcc package with some versioning for gcc itself (not for the package only). Then we can mark incompatibilities. I think this proper solution is more work. But it's more precise and it can be genrealised to other conf- packages…

[mseri]

I am not sure we have a proper way of dealing with it. For old packages, we can consider adding avoid-version since they are likely unused, and this way can still be pinned by whom really needs them

[hannesm]

The other question for conf* packages is whether we should add x-maintenance-intent there as well? E.g. looking into conf-gmp, my gut feeling is that only the latest version is relevant.. and this may be true for others (certainly not for every conf package though).