Add libmsgpack-c{,-static} as outputs of mspack-c-feedstock

[jjerphan]

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

• I want to copy an artifact following CFEP-3:

  • Pinged the relevant feedstock team(s)
  • Added a reference to the original PR
  • Posted a link to the conda artifacts
  • Posted a link to the build logs

• I want to add a package output to a feedstock:

  • Pinged the relevant feedstock team(s)
  • Added a small description of why the output is being added.

msgpack-c is distributed as a shared library with eponymous packages.

This propose to add:

• libmsgpack-c for distributing the shared library
• libmsgpack-c-static for distributing the static library following CFEP-18's conventions.

See conda-forge/msgpack-c-feedstock#50 and conda-forge/msgpack-c-feedstock#53.

Ping @conda-forge/msgpack-c.

[xhochy]

Can you please link the relevant PR here?

[jjerphan]

I edited the description accordingly.

[isuruf]

Add lib prefix ?

[jjerphan]

And have libmsgpack-c-static when we currently have msgpack-c?

[isuruf]

Yes. I'd prefer that.

[jjerphan]

Should we then switch msgpack-c to libmsgpack-c (like what happened to abseil and arrow-cpp)?

[isuruf]

That's upto @conda-forge/msgpack-c. We already have python and libpython-static, so it's not without precedent.

[traversaro]

I do not have any specific preference, if other conda-forge members prefer libmsgpack-c-static that is perfectly fine for me.

[h-vetinari]

The static library should start with lib. The question is whether the shared library also gets renamed (== becomes a wrapper around a new libmsgpack-c that then contains the actual shared library)

[jjerphan]

Could we for instance introduce libmsgpack-c and have the current msgpack-c be repurposed to be an empty package depending on parts or on all the outputs of its feedstock, i.e. on libmsgpack-c (and libmsgpack-c-static and subsequent outputs in the future if any)?

[h-vetinari]

have the current msgpack-c be repurposed to be an empty package depending on libmsgpack-c

That's what my (==...) was describing.

(and libmsgpack-c-static)?

This should not be part of msgpack-c.

[jjerphan]

See conda-forge/msgpack-c-feedstock#53.