pin expat 2.5

[minrk]

vtk, at least, won't run with expat 2.6, so keep building packages with expat 2.5 for now

alternative:

• don't do this, and let vtk be incompatible with other expat-linking packages built after last week's release of expat 2.6 until we get a patch for https://gitlab.kitware.com/vtk/vtk/-/issues/19258

expat 2.5 has run_exports >=2.5,<3, so 2.6 will still be used at runtime, which I understand to be correct in general, despite an incompatibility (not ABI-related) with 2.6 that has come up in vtk in particular.

xref:

• vtk is incompatible with expat 2.6 vtk-feedstock#321
• vtk is not compatible with libexpat 2.6 conda-forge-repodata-patches-feedstock#682

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[hmaarrfk]

thoughts from others?

I'm sympathetic to this issue, but maybe we can add a note and a "time bound" to release the pin?

[minrk]

FWIW, I'm not sure we need this. I don't know how many packages:

• depend on expat
• don't depend on vtk or anything else that depends on vtk
• will be used in the same env with vtk
• are likely to get updates before vtk gets a patch for expat 2.6

because all of those need to be true for this pinning to cause a problem for users.

• if they depend on vtk, the pinning gets applied already
• if they aren't used together with vtk, there's no issue
• if they are used with vtk, the only consequence is builds before last week will be used instead of the latest

So I'm also fine with waiting for pinning back expat in vtk to start seeing issues. That's largely why I didn't open this originally when opening conda-forge/conda-forge-repodata-patches-feedstock#682

[minrk]

The first conflict with the pinning has already happened with gdal: robotology/robotology-superbuild#1607

So maybe this is a good idea for now.

[hmaarrfk]

I somewhat want to wait for others from core to get a chance to jump in and comment. Or maybe they can just click merge since I've approved. A second vote of approval would go a long way for me.

The first conflict with the pinning has already happened with gdal: robotology/robotology-superbuild#1607

Maybe make a PR to pin libexpat in GDAL while you wait. I did the same thing for protobuf on a few key repositories:
conda-forge/openvino-feedstock#82

[minrk]

Yeah, I'm okay either way. I don't think it's too pressing. Hopefully the vtk issue can be resolved soon.

[xhochy]

As the run_exports pin is major, I'm fine with this special change.

[traversaro]

The first conflict with the pinning has already happened with gdal: robotology/robotology-superbuild#1607

Maybe make a PR to pin libexpat in GDAL while you wait. I did the same thing for protobuf on a few key repositories: conda-forge/openvino-feedstock#82

Thanks for the suggestion. For that specific case we are fine just waiting.

[minrk]

VTK has a patch, which doesn't appear to be ABI-compatible, so I think that means we need to wait for a VTK release. Given that, and I'm not sure what the VTK release time scale is, I think this pin is probably a good idea. Reiterating that it only holds expat back at build-time, 2.6 is still acceptable at runtime for everything but vtk. Not sure what other folks think.

[h-vetinari]

We need expat 2.6 for some CVE fixes in python already at build time. I think vtk should just do

expat:
  - 2.5

in CBC (and if there are necessary host-dependencies that also depend on expat, then those as well), but not impose this constraint on the rest of conda-forge.

[minrk]

OK, if there's a strong reason why expat must be 2.6 at build time and not just runtime, there's no need to do this. VTK has its pinning applied already (pinning in CBC doesn't address the problem, as described above), so VTK will just have to conflict with all other conda-forge packages that link expat until there's a new VTK version.