Conan: [question] What is "unrelated mode" side effect if use it to solve dependency conflict ?

[gallencalade]

There are three packages and their dependency relationship in requires in conanfile.py:

pkg-A: 0.1, 0.2
pkg-B: 0.1 -> pkg-A 0.1
pkg-C: 0.1 -> pkg-A 0.2 and pkg-B 0.1

In fact, there is an error that missing pkg-B 0.1 built with pkg-A 0.2. Because of the working-net environment, I can not get the source of pkg-B to build it with pkg-A 0.2. I found I can use default_package_id_mode = unrelated_mode in conan.conf to escape this error. Is it right to solve this problem in this way ? Is there any side effect ?

PS: Our programmers would like to use a difference version A in C requirements for some reason but without concern about B, while other packages may download package B and package A without requires A explicitly.

Thank you!

[memsharded]

Hi @gallencalade

Yes, going unrelated_mode can have bad effects, like incomplete applications, old code running, binary incompatibility... It really depends on your source code, the changes that are done between version pkg-a versions 0.1 and 0.2, etc.

The safest approach in all cases is to build new binaries. It is very likely that pkg-B/0.1 built with pkgA/0.1 is a different binary that pkg-B/0.1 linked with pkg-A/0.2. Actually, lots of the recent changes in Conan, based on users feedback and requests, have been in the opposite direction, to provide recipe_revision_mode and package_revision_mode, which implies that if anything change in the recipe, even if you are not bumping its version, it will still require the downstream consumers to build new binaries.

This is usually a task for CI, and managing your binaries at scale, and also the reason some of the recent advances in lockfiles and things like conan lock build-order have been implemented.

With these tools, users requesting pkg-B/0.1 will get the right binaries they need, depending on the upstream versions they are using too.

Please let me know if this clarifies the issue.

[gallencalade]

Well, all the packages are shared libs. Even if the shared lib is changed, except interfaces in header files, we also have to build a new binary. May be, it is a temporary and risky way to use default_package_id_mode = unrelated_mode.

Thank you!