Dubious warnings about versions being overridden

[sztomi]

Conan version: 1.18.2
Ubuntu 19.04

We have meta-packages that list a subset of all our packages, meant to be built with a set of our configurations (build profiles). In these meta-packages, we list some, but not all of the packages in the tree. In 1.18.2 we are getting lots of warnings about a version being overridden to the same version. I understand this is because these are redundant. However, there isn't a real version collision going on here. I think this warning should be reserved for cases when there is an actual collision. Otherwise it's difficult to dig out the real collisions.

In the following example, nano is one of the meta-packages I mentioned above.

WARN: boost/1.69.0 requirement zlib/1.2.8 overridden by nano/1.0 to zlib/1.2.8
WARN: boost/1.69.0 requirement iconv/1.15 overridden by nano/1.0 to iconv/1.15
WARN: libxml2/2.9.8 requirement zlib/1.2.8 overridden by nano/1.0 to zlib/1.2.8
WARN: plex-openssl/1.0.2p requirement zlib/1.2.8 overridden by nano/1.0 to zlib/1.2.8
WARN: opencv/2.4.13-07711e4 requirement zlib/1.2.8 overridden by nano/1.0 to zlib/1.2.8
WARN: soci/3.0.0-9a9baa1 requirement sqlite/3.26.0 overridden by nano/1.0 to sqlite/3.26.0
WARN: soci/3.0.0-9a9baa1 requirement boost/1.69.0 overridden by nano/1.0 to boost/1.69.0
WARN: soci/3.0.0-9a9baa1 requirement zlib/1.2.8 overridden by nano/1.0 to zlib/1.2.8
WARN: soci/3.0.0-9a9baa1 requirement iconv/1.15 overridden by nano/1.0 to iconv/1.15
WARN: curl/7.56.1 requirement plex-openssl/1.0.2p overridden by nano/1.0 to plex-openssl/1.0.2p
WARN: curl/7.56.1 requirement zlib/1.2.8 overridden by nano/1.0 to zlib/1.2.8
WARN: libidn/2.0.5 requirement iconv/1.15 overridden by curl/7.56.1 to iconv/1.15
WARN: taglib/1.11.1 requirement zlib/1.2.8 overridden by nano/1.0 to zlib/1.2.8
WARN: taglib/1.11.1 requirement boost/1.69.0 overridden by nano/1.0 to boost/1.69.0
WARN: cppnetlib/0.13.0 requirement boost/1.69.0 overridden by nano/1.0 to boost/1.69.0
WARN: cppnetlib/0.13.0 requirement zlib/1.2.8 overridden by nano/1.0 to zlib/1.2.8
WARN: cppnetlib/0.13.0 requirement iconv/1.15 overridden by nano/1.0 to iconv/1.15
WARN: minizip/1.2.8 requirement zlib/1.2.8 overridden by nano/1.0 to zlib/1.2.8

---

• I've read the CONTRIBUTING guide.
• I've specified the Conan version, operating system version and any tool that can be relevant.
• I've explained the steps to reproduce the error or the motivation/use case of the question/suggestion.

[jgsogo]

Hi, @sztomi . Can you provide a graph that reproduces this issue, please? I agree with you that we should get rid of those redundant messages.

[sztomi]

Sure - I'll post a repro case in a bit.

[sztomi]

@jgsogo - here is a repro case https://github.com/sztomi/dubious_warnings

Please take a look at the ffmpeg conanfile - I think I found a different bug while I put this together.

[jgsogo]

Thanks for the example, now I can reproduce the issue, it is somehow related to the graphlock but I need to investigate it further (same for the other possible issue you pointed out).

[jgsogo]

Hi, @sztomi. I've spotted the issue: you are introducing several diamonds in your graph with the meta-package nano recipe, and in your recipe files you are requiring dependencies using the name/version. Everything works as expected.

When you call using the conan.lock file Conan will use the references with the revision (have a look at the lockfile) while the requirements in the recipes don't have revision. At some point during the graph resolution Conan will check if the requirement resolved down in the graph (with the revision from the lockfile) and the requirement declared in the recipe are equal. Comparaison fails and we get the WARNING.

I think we should reorder a couple of steps in the graph algorithm, I'll propose the change, let's see if it has any collateral effects.

[sztomi]

@jgsogo thanks

you are introducing several diamonds in your graph with the meta-package nano recipe, and in your recipe files you are requiring dependencies using the name/version

Hmm, so in other words, the problem is that we are requiring some "root" packages (ones that have no dependencies themselves) as well as others (leaves and stuff in-between)?

[jgsogo]

With those meta packages you are creating diamonds in the graph, that's ok and Conan is prepared to deal with this situation.

Using the graphlock in the last command of your example, the situation is as follows (just for the variant, ffmpeg and harfbuzz diamond). The graph algorithm is as follows:

• variant requires harfbuzz/1.0 in the recipe
• the graphlock is applied, harfbuzz/1.0 takes the revision from the lockfile, now it is harfbuzz/1.0#<revision>.
• ffmpeg requires harfbuzz/1.0 in the recipe (no revision specified)
• Conan compares both nodes: harfbuzz/1.0 != harfbuzz/1.0#<revision> and raises the warning.

We are getting a false negative, one solution would be to override the equal operation in order to evaluate harfbuzz/1.0 (without revision) equal to any other harfbuzz/1.0#<revision> (explicit revision). My implementation in the PR is more conservative.

[sztomi]

Thank you for handling this quickly!