boost: bump dependencies

[SpaceIm]

Specify library name and version: lib/1.0

This is also a good place to share with all of us why you are submitting this PR (specially if it is a new addition to ConanCenter): is it a dependency of other libraries you want to package? Are you the author of the library? Thanks!

---

• I've read the guidelines for contributing.
• I've followed the PEP8 style guides for Python code in the recipes.
• I've used the latest Conan client version.
• I've tried at least one configuration locally with the
  conan-center hook activated.

[ghost]

I detected other pull requests that are modifying boost/all recipe:

• [boost] Apply patch to fix https://github.com/boostorg/graph/issues/268 #6132

This message is automatically generated by https://github.com/ericLemanissier/conan-center-conflicting-prs so don't hesitate to report issues/improvements there.

[conan-center-bot]

All green in build 1 (ee5ce43cc8004ae43f3740563f94b471853bac77):

• boost/1.78.0@:
  All packages built successfully! (All logs)

• boost/1.70.0@:
  All packages built successfully! (All logs)

• boost/1.72.0@:
  All packages built successfully! (All logs)

• boost/1.69.0@:
  All packages built successfully! (All logs)

• boost/1.75.0@:
  All packages built successfully! (All logs)

• boost/1.76.0@:
  All packages built successfully! (All logs)

• boost/1.73.0@:
  All packages built successfully! (All logs)

• boost/1.74.0@:
  All packages built successfully! (All logs)

• boost/1.77.0@:
  All packages built successfully! (All logs)

• boost/1.71.0@:
  All packages built successfully! (All logs)

[conan-center-bot]

This PR has been automatically merged due Bump version or Bump dependencies label.
Read https://github.com/conan-io/conan-center-index/blob/master/docs/labels.md#bump-version to obtain more information.

[garethsb]

@SpaceIm this change has broken our build:

  cpprestsdk/2.10.18: Not found in local cache, looking in remotes...
  cpprestsdk/2.10.18: Trying with 'conancenter'...
  Downloading conanmanifest.txt
  Downloading conanfile.py
  Downloading conan_export.tgz
  cpprestsdk/2.10.18: Downloaded recipe revision 003f5d46fb101c1d3bba72cf0ab781a2
  ERROR: Not able to automatically detect '/usr/bin/cc' version
  WARN: Remotes registry file missing, creating default one in /home/runner/.conan/remotes.json
  WARN: boost/1.78.0: requirement zlib/1.2.12 overridden by cpprestsdk/2.10.18 to zlib/1.2.11 
  ERROR: boost/1.78.0: Incompatible requirements obtained in different evaluations of 'requirements'
      Previous requirements: [zlib/1.2.12, bzip2/1.0.8, libbacktrace/cci.20210118]
      New requirements: [zlib/1.2.11, bzip2/1.0.8, libbacktrace/cci.20210118]
  CMake Error at /home/runner/work/nmos-cpp/build/conan.cmake:522 (message):
  Error:   Conan install failed='1'

[SpaceIm]

conan-center cannot prevent version conflict between last RREV of all recipes at any given time, since only one recipe can be updated per PR and conan-center doesn't allow version range. In the meantime, we can't freeze all dependencies versions in recipes forever.
You should use a lockfile or explicitly override all versions of transitive dependencies in your root conanfile.

/cc @SSE4 @jgsogo @uilianries @danimtb

[garethsb]

Thanks, OK. My dependency graph is like:

• my project
  • nmos-cpp
    • cpprestsdk
      • boost
        • zlib (1)
      • zlib (2)
    • boost
      • zlib (3)
    • (4)
  • (5)

If I've understood correctly, (2) is allowed to override (1), but when (2) and (3) are different this causes a problem.

So solution could be:

• update cpprestsdk recipe (2) to be same as (1) (zlib/1.2.12) but that will break again next time
• add explicit/direct dependency at (4) (zlib/1.2.Z (Z = 11 or 12) but explicit version for what is actually an indirect dependency seems inelegant
• use explicit dependencies in my project at (5), or a lockfile?

Right?

[SpaceIm]

Correct

add explicit/direct dependency at (4) (zlib/1.2.Z (Z = 11 or 12) but explicit version for what is actually an indirect dependency seems inelegant

It's tedious to maintain, but at least you can use self.requires("foo/x.y.z", override=True) to clearly highlight transitive dependencies, and avoid "direct" meaning.

lockfile?

I think it's the approach promoted by conan team.

[garethsb]

For recipes held in CCI, we want the out-of-box experience to be as friendly as possible. In this case, anyone picking up the nmos-cpp recipe will currently encounter this issue. Therefore do we need a Conan Center policy that recipes SHOULD list their indirect dependencies, i.e. in this case, nmos-cpp recipe should be adjusted?

If so, let's try... I can make PR to update nmos-cpp recipe with self.requires("zlib/1.2.11", override=True) before another PR to update cpprestsdk with zlib/1.2.12 (and then ultimately a PR for nmos-cpp to self.requires("zlib/1.2.12", override=True)).

[SpaceIm]

I understand the pain, but listing indirect dependencies in conan-center recipes is against its policy actually.

[garethsb]

So how DO we support users?

[jgsogo]

Hi!

There will always be conflicts for the reasons given above. If we want to provide binaries we need to run the builds, and we cannot afford to build the full graph to ensure there are no conflicts (and there are binaries). So, whenever there is a NEW diamond (created by the user consuming recipes) in the dependency graph, a conflict might happen for requirement versions, options values,... diamonds are always a problem.

How to deal with it? When the consumer finds a diamond they need to fix it by providing an override downstream. Hopefully some of those users will fix the diamond and will provide a PR in this repository.

How to prevent it from failing again in your local project? https://github.com/conan-io/conan-center-index/blob/master/docs/faqs.md#how-to-protect-my-project-from-breaking-changes-in-recipes

Are there plans to alleviate it: #10181

Listing all transitive dependencies won't fix the issue: the user can still consume two unrelated trees of dependencies from ConanCenter, and those branches could have conflicts.

[garethsb]

Thanks for the info, mostly understood.

I'm not clear from this:

Hopefully some of those users will fix the diamond and will provide a PR in this repository.

whether you recommend adding override requirements in CCI recipes that have 🔷 diamonds or not?

Since this problem can affect end users even if diamonds within CCI were solved, could it be helpful if the error message from Conan had a pointer to the FAQ for more info?

   ERROR: boost/1.78.0: Incompatible requirements obtained in different evaluations of 'requirements'
      Previous requirements: [zlib/1.2.12, bzip2/1.0.8, libbacktrace/cci.20210118]
      New requirements: [zlib/1.2.11, bzip2/1.0.8, libbacktrace/cci.20210118]

[jgsogo]

I'm not clear from this:

Hopefully some of those users will fix the diamond and will provide a PR in this repository.

whether you recommend adding override requirements in CCI recipes that have 🔷 diamonds or not?

No. I don't recommend that. Reasons:

• for those scenarios where it is possible (diamond is present in CCI) there would make it hard to bump requirements. It would require more PRs (too much CI time). Besides users, we will also try to provide some automation to create these PRs.
• still, there will always be diamonds created by consumers of recipes from CCI, so we would never be able to claim that the problem is gone.

Since this problem can affect end users even if diamonds within CCI were solved, could it be helpful if the error message from Conan had a pointer to the FAQ for more info?

   ERROR: boost/1.78.0: Incompatible requirements obtained in different evaluations of 'requirements'
      Previous requirements: [zlib/1.2.12, bzip2/1.0.8, libbacktrace/cci.20210118]
      New requirements: [zlib/1.2.11, bzip2/1.0.8, libbacktrace/cci.20210118]

IIRC, we improved the message for this error and now it tells which are the two recipes that list the incompatible versions. Anyway, if you think the message can be improved, create the issue with the proposal in the Conan client repository. Thanks!