Switch to openssl 3.0 in host

[xylar]

Drop openssl from gdal (but not libgdal)

Checklist

• [x] Used a personal fork of the feedstock to propose changes
• [x] Bumped the build number (if the version is unchanged)
• [x] Re-rendered with the latest conda-smithy (Use the phrase code>@<space/conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• [x] Ensured the license file is being packaged.

closes #886

[conda-forge-webservices[bot]]

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.

[xylar]

@conda-forge-admin, please rerender

[akrherz]

I don't think this will help much as there's till plenty of downstream requirements of libgdal that will have openssl >=3.2 requirements, ie postgresql ...

I also don't understand where within the build system the openssl>=3.2 gets set given what is in conda-forge-pinning and what openssl run_exports are set to.

[xylar]

@akrherz, the downstream dependencies aren't the problem. It's the upstream dependencies that matter and, yes, there are too many of them to let us go back to an earlier openssl :-(

[xylar]

I also don't understand where within the build system the openssl>=3.2 gets set given what is in conda-forge-pinning and what openssl run_exports are set to.

I'm pretty sure that's a fundamental property of conda-build. It pins the run version to be >= the version used to build the package.

[xylar]

I'm going to close this, since it's not a practical solution.

[rouault]

It pins the run version to be >= the version used to build the package.

IMHO, that's a very reasonable feature, not a bug. For example PROJ 9.2 is backwards compatible of PROJ 9.1, ie a GDAL built against PROJ 9.1 will run against PROJ 9.2, but if you build GDAL against PROJ 9.2, it may use new symbols introduced in PROJ 9.2 and not present in 9.1. For openssl, we don't have code that tests openssl >= 3, but perhaps there are #define macros that resolve to different function names, or tricks like that, which also make it impractical to run a GDAL built against openssl 3.2 with 3.0

[xylar]

@rouault, I completely agree. It's based on the assumption that packages are forward compatible but not necessarily backward compatible, which is a common feature of minor revisions.

I don't think there would be a problem with going back to openssl 3.0 at build time here. We would still be compatible with v3.2 at runtime. But we can't do that without also doing it for all the upstream dependencies that currently use openssl > 3.0 and that's not a project I'm willing to take on.