Add PCRE2 compatibility patch

[jaimergp]

Checklist

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

Adds patch from openSUSE/libsolv#506.

This enables supports for properly merged glob strings in conda-libmamba-solver, as implemented in conda/conda#11612

Please review the patch, this is a bit beyond my comfort zone, both CMake and C 😬

[conda-forge-linter]

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.

[jaimergp]

@conda-forge-admin, please rerender

[wolfv]

nice!

There are two additional considerations -- we should figure out if we can have a pcre2-static on conda-forge (for micromamba) and also add a recipe to boa-forge :)

[jaimergp]

PCRE2 PR submitted here: conda-forge/pcre2-feedstock#31

[jezdez]

For defaults the patch is in AnacondaRecipes#2

[jaimergp]

@wolfv, PCRE2 10.40 is now available with a static lib too. Let me know if you need something else!

[wolfv]

nice!

[jaimergp]

I think we need a pcre2 migrator to push 10.37 to 10.40 if you want the static libs now.

[jaimergp]

Also note this warning:

The install/build script(s) for libsolv deleted the following files (from dependencies) from the prefix:
['lib/libbz2.a', 'lib/libz.a']
This will cause the post-link checks to mis-report. Please try not to delete and files (DSOs in particular) from the prefix
WARNING:conda_build.build:The install/build script(s) for libsolv deleted the following files (from dependencies) from the prefix:
['lib/libbz2.a', 'lib/libz.a']

So it looks like the build scripts do not want static libs at all, and hence we shouldn't depend on pcre2-static? Wouldn't the libsolv compilation create the static lib on its own from the shared libs anyway?

[jaimergp]

@wolfv ping :D

[wolfv]

I am about to release mamba / libmamba / micromamba 1.0 -- if it's OK let's wait after the release? I am also fixing some libarchive / curl issues in feedstocks specific to micromamba right now...

I really want to get this in, btw. sorry if it appears as if I was stalling this.

[jaimergp]

1.0 👀 That's exciting!!

No worries, I had forgotten myself 😬 I was just going through my GH notifications and found it again, fortunately. It's not super urgent, but it's blocking conda/conda#11612

[jaimergp]

@wolfv gentle reminder :D

[jaimergp]

@conda-forge-admin, please rerender

[varlackc]

There are currently some merge conflicts on the branch.
We might need to resolve the conflicts before approving.

In addition it might be a good idea to also add the doc_url.

[jaimergp]

@conda-forge-admin, please rerender

[conda-forge-webservices]

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

I was trying to look for recipes to lint for you, but it appears we have a merge conflict.
Please try to merge or rebase with the base branch to resolve this conflict.

Please ping the 'conda-forge/core' team (using the @ notation in a comment) if you believe this is a bug.

[AntoinePrv]

@jaimergp is this for libmamba?

[jaimergp]

This is required for compatibility with conda/conda#11612, which requires advanced regexes internally. But if libmamba is going to be parsing things outside libsolv now maybe we don't need it anymore?

[AntoinePrv]

That would be our plan, but it is still unclear how we can plug a matchspec callback into libsolv.
But isn't matching not trusted regex from repodata.json a DOS security risk?

[jaimergp]

We can still sanitize user input and avoid the DOS (which is already a problem today in current conda, given it allows pkg[build=/^some[-]regex$/] specs. Those advanced regexes are generated internally to accommodate the merge of several *build_string* globs à la *_gpu* or _*gpu_cuda11 (these two are compatible but conda would reject them now).

[AntoinePrv]

I was thinking of only allowing them in user input, not package input.
The globs are different from the regex aren't they? They are already implemented libsolv AFAIK.

[jaimergp]

The globs are converted internally to regexes after they pass the merge step (which in current conda is only checking whether they are the same string or not). What the PR I linked above proposed is using lookahead regexes to handle the merge (instead of strict equals). The discussion there contains all the details you need!

[AntoinePrv]

On Mamba the globs are not converted to regex, and I think also not on libsolv.

[jaimergp]

With conda-libmamba-solver, we take the MatchSpec objects as generated by conda. If that PR was to be merged, then we could receive MatchSpec objects with a build string that has a lookahead regex, and then libsolv would crash because that kind of regex is not supported by the current regex engine. It does accept simpler regexes, just not lookaheads and similar.

[AntoinePrv]

Closing as stale and conflicted. Feel free to reopen.

[jaimergp]

I can confirm we don't need this anymore because of the new mamba matchspec parser.