[question] Why requirement overridden by conanfile.txt does not affect package id?

[mmatrosov]

I have the following conanfile.txt:

[requires]
boost/1.75.0-crypto1#4a232389c0e69e97cd1ba355746f3240
folly/2021.05.17.00#22a858c5a5f37e56090a4fe7ff253130

When I run conan install conanfile.txt here is what I see:

Requirements
    boost/1.75.0-crypto1 from local cache - Cache
    folly/2021.05.17.00 from local cache - Cache
Packages
    boost/1.75.0-crypto1:5192f911b1d09eae3e8ed7d7ccb33c7e49d1a208 - Cache
    folly/2021.05.17.00:9e1fadd5f24432ec43e01f6416e3ea0a3d6121dc - Download

WARN: folly/2021.05.17.00: requirement boost/1.75.0 overridden by your conanfile to boost/1.75.0-crypto1 

And let's take a look at the selected folly package:

$ conan search folly/2021.05.17.00@
Existing packages for recipe folly/2021.05.17.00:

    Package_ID: 9e1fadd5f24432ec43e01f6416e3ea0a3d6121dc
        [options]
            fPIC: True
            shared: False
        [settings]
            arch: x86_64
            build_type: Release
            compiler: clang
            compiler.cppstd: 20
            compiler.libcxx: libstdc++11
            compiler.version: 12
            os: Linux
        [requires]
            boost/1.75.0:5192f911b1d09eae3e8ed7d7ccb33c7e49d1a208
            <other reqs>
        Outdated from recipe: False

Conan aknowledged that I am using custom boost version 1.75.0-crypto1, but it uses folly package built against a different boost version 1.75.0! Why is that so? I would expect folly to be rebuilt with my version of boost.

I can see how packages for both boost/1.75.0-crypto1 and boost/1.75.0 have the same package id. I assume this is ok since they are using the same settings, options and requires. But they have different version, which should affect requries for folly yielding different package ids for builds against boost/1.75.0-crypto1 and boost/1.75.0.

• [x] I've read the CONTRIBUTING guide.

[memsharded]

Hi @mmatrosov

This happens, because the default package_id_mode regarding dependencies is semver_direct_mode. So a package like folly will not produce a new package_id unless the dependencies bumped to the major version. That was designed following the semver specification, which happened to be not that good for C++ binaries versioning. We have allowed to change and configure the default_package_id_mode to use more restrictive policies, try to change it (the only caveat is that ConanCenter binaries are built with the default, when changing this, you will need to build the binaries from source, because different package_id will be computed)

[mmatrosov]

Ok, I see, thanks. Do you consider changing the default to a safer one?

[memsharded]

Ok, I see, thanks. Do you consider changing the default to a safer one?

Absolutely, but not now in 1.X, because that would be breaking. It has already been changed in a proposal develop2 branch for Conan 2.0, and it will probably be iterated until 2.0 release.

[mmatrosov]

Hi, @memsharded

I cannot find a proposal related to default_package_id_mode in conan tribe repo. Is there a list of "proposal ideas" somewhere?

[memsharded]

Hi @mmatrosov

Good question. We already have a draft exactly about this, we are currently working on. It is a complicated to explain proposal, hopefully it will be ready in a couple of days, keep tuned to the tribe repo.