Fix wrong bz2 dependency in Windows .pc pkg-config file

[traversaro]

This PR fixes the issue reported in #20 .

Checklist

• Used a 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.

[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.

[traversaro]

@conda-forge-admin, please rerender

[traversaro]

If the project is ever updated to the latest version, the patch will need to be updated with this one:
https://github.com/traversaro/libzip/commit/54bbb4e5919eb5860df4f7bab4d208db2014e760.patch .

[traversaro]

The only listed mantainer is @ceholden but he does not seem really active, what is the correct way to proceed in this case. cc @conda-forge/help-c-cpp . If it helps, I will be happy to be added as a mantainer.

[traversaro]

Upstream issue: gazebosim/docs#96 .

[traversaro]

cc @wolfv (this fixes an issue in ignition-fuel-tools when compiled when pkg-config is installed)

[wolfv]

Hi @traversaro usually we wait for 3 days for the maintainers to respond. Let's see if @ceholden responds today, and if not we can merge with core-rights.
Would be great to get a later version in as well. I might have a look.

[traversaro]

Hi @traversaro usually we wait for 3 days for the maintainers to respond. Let's see if @ceholden responds today, and if not we can merge with core-rights.

Perfect, if that is the policy we can also wait for full 3 days, no problem on my side.

[traversaro]

As there was only one maintainer that seems currently unavailable, I added myself as a mantainer as part of this PR.

[wolfv]

thanks @traversaro for picking this up!

I think we could release a new version, but we might have issues with the DLL compatibilities ...

The usual way is to globally pin a version in the conda-forge pinnings file: https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/master/recipe/conda_build_config.yaml and then start a "migrator" for all projects depending on libzip.

I am just mentioning this in case you wanted to release a newer version, I don't know what other downstream packages depend on libzip.

[traversaro]

thanks @traversaro for picking this up!

I think we could release a new version, but we might have issues with the DLL compatibilities ...

The usual way is to globally pin a version in the conda-forge pinnings file: https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/master/recipe/conda_build_config.yaml and then start a "migrator" for all projects depending on libzip.

I am just mentioning this in case you wanted to release a newer version, I don't know what other downstream packages depend on libzip.

Thanks, this is good to know. I will check the ABI policy of libzip and understand if it make sense to add a run_exports for this repo (as it is installing shared libraries). Hopefully if the ABI policy of libzip is to break only on major version change, we could bump the minor version without worrying too much of creating problems downstream.

[wolfv]

by using mamba repoquery whoneeds libzip -c conda-forge I was able to find that only qgis and libignition-fuel-tools4 seem to depend on libzip.

Just as a FYI

[traversaro]

thanks @traversaro for picking this up!
I think we could release a new version, but we might have issues with the DLL compatibilities ...
The usual way is to globally pin a version in the conda-forge pinnings file: https://github.com/conda-forge/conda-forge-pinning-feedstock/blob/master/recipe/conda_build_config.yaml and then start a "migrator" for all projects depending on libzip.
I am just mentioning this in case you wanted to release a newer version, I don't know what other downstream packages depend on libzip.

Thanks, this is good to know. I will check the ABI policy of libzip and understand if it make sense to add a run_exports for this repo (as it is installing shared libraries). Hopefully if the ABI policy of libzip is to break only on major version change, we could bump the minor version without worrying too much of creating problems downstream.

According to nih-at/libzip#218 we should be safe to go, we just need to add a run_exports similar to the one of ignitionrobotics projects.