Please come up with an alternative to 'available: os != "win32"' for Windows packages failing CI about opam-repository HOT 2 OPEN

Yes, indeed; the mechanisms were listed in #25861:

• available: os != "win32" is the sledgehammer: no Windows support at all
• conflicts: "host-system-msvc": this package works with the mingw-w64 ports, but doesn't work with the Visual Studio ports
• conflicts: "host-arch-x86_32": this package doesn't work on 32-bit Intel
• depends: "host-system-mingw": this package only works with the mingw-w64 ports.

I expect that conflicting host-system-mingw is the least dispruptive thing to do at the moment, and that also reflects what CI is actually testing here.

Another thing we could try, unless it becomes too disruptive, is that existing packages should not be constrained away from Windows in other PRs - i.e. let's open an issue or a separate PR first where those concerned can be pinged both to triage and ack the change?

from opam-repository.

Another thing we could try, unless it becomes too disruptive, is that existing packages should not be constrained away from Windows in other PRs - i.e. let's open an issue or a separate PR first where those concerned can be pinged both to triage and ack the change?

I like this idea

from opam-repository.