Mark azure-core-cpp 1.11 broken on linux

[jorisvandenbossche]

See conda-forge/tiledb-feedstock#228 (comment) for context. This latest release breaks tiledb (which doesn't have a strict pin on the azure-core-cpp version, just <2), and in that way also breaks eg libgdal.

In our CI where we noticed this, it's only on Linux that we see the crash, not on Windows or Mac. Therefore I only marked the linux packages as broken. We only test linux-64, but I marked aarch64 and pplc as well (assuming those would have the same issue?)

cc @conda-forge/azure-core-cpp

Guidelines for marking packages as broken:

• We prefer to patch the repo data (see here)
  instead of marking packages as broken. This alternative workflow makes environments more reproducible.
• Packages with requirements/metadata that are too strict but otherwise work are
  not technically broken and should not be marked as such.
• Packages with missing metadata can be marked as broken on a temporary basis
  but should be patched in the repo data and be marked unbroken later.
• In some cases where the number of users of a package is small or it is used by
  the maintainers only, we can allow packages to be marked broken more liberally.
• We (conda-forge/core) try to make a decision on these requests within 24 hours.

What will happen when a package is marked broken?

• Our bots will add the broken label to the package. The main label will remain on the package and this is normal.
• Our bots will rebuild our repodata patches to remove this package from the repodata.
• In a few hours after the anaconda.org CDN picks up the new patches, you will no longer be able to install the package from the main channel.

Checklist:

• I want to mark a package as broken (or not broken):

  • Added a description of the problem with the package in the PR description.
  • Pinged the team for the package for their input.

• I want to archive a feedstock:

  • Pinged the team for that feedstock for their input.
  • Make sure you have opened an issue on the feedstock explaining why it was archived.
  • Linked that issue in this PR description.
  • Added links to any other relevant issues/PRs in the PR description.

• I want to request (or revoke) access to an opt-in CI resource:

  • Pinged the relevant feedstock team(s)
  • Added a small description explaining why access is needed

[jjerphan]

LGTM.

Thank you for having taken care of it, @jorisvandenbossche. 🙂

[jdblischak]

I appreciate that speed was desired to fix this, but I think this would have been better solved with a repodata patch. There is nothing inherently wrong with azure-core-cpp 1.11.0 binaries. The problem is that it broke tiledb, so we need to patch its metadata to include an upper limit of <1.11. The azure-core-cpp recipe uses "run exports", so if any conda binaries were built against azure-core-cpp 1.11.0 over the weekend, they are now unusable (because it uses the default of min_pin="x.x.x.x").

Since there is nothing wrong with the 1.11.0 binaries themselves, I propose the following plan:

• Patch the tiledb repodata to include azure-core-cpp < 1.11 (Set upper_bound of 1.11.0 for tiledb binaries that depend on azure-core-cpp conda-forge-repodata-patches-feedstock#639)
• Mark the azure-core-cpp binaries as unbroken New 1.11.0 binaries with a stricter run exports were created from Set run_exports max_pin to x.x azure-core-cpp-feedstock#11, so no need to restore the previous ones with the looser run exports
• Update the tiledb recipe to specify azure-core-cpp < 1.11 Require azure-core-cpp <1.11 tiledb-feedstock#229

Longer term, I think we should update the run exports of azure-core-cpp to be max_pin="x.x" (conda-forge/azure-core-cpp-feedstock#11). We trusted the upstream developers that minor patches would be backwards compatible, but that clearly isn't the case. Had the setting been max_pin="x.x", then the new azure-core-cpp 1.11 would not have been installed with tiledb in the first place. We should also consider this for the other Azure C++ SDK library recipes.

cc @teo-tsirpanis

[jdblischak]

Sorry, I missed the discussion in conda-forge/tiledb-feedstock#228 where it was decided to mark them as broken