[bug] binary cache not used, claim is same settings and options but different dependencies, dependencies looks identical to me

[hpe-ykoehler]

Describe the bug

I have a situation where the binary cache is not being used.

The conan graph explain says that the following:

        dependencies
          expected: hiredis/1.1.Z, libev/4.33.Z
          existing: hiredis/1.1.0#312991eb91791ad706f038d6a8383c63:be712621cf2b2bb3dfabbbfedf4c2b102294b18a, libev/4.33#8fc921587a3733e276520386c84ac583:5e6e38e5a54ca49246fc1eefcd6700d1d71fa40f
        explanation: This binary has same settings and options, but different dependencies

using conan 2.9.1

Yet we can see above that hiredis 1.1.0 is same as 1.1.Z and libev 4.33 should be treated same as 4.33.Z but apparently it is not.explains

How to reproduce it

Create a package with libev 4.33 as a dependency, seems that because the version has only two parts, the cache binary system fails to recognized it as greater or equal version.

(assuming I misunderstand the underlying bug)

[hpe-ykoehler]

I believe the same is occurring with pcre2 which also have 2 parts only in its version.

[memsharded]

Hi @hpe-ykoehler

Thanks for your report. This doesn't look a bug so far. The conan graph explain is reporting:

expected: hiredis/1.1.Z, libev/4.33.Z
existing: hiredis/1.1.0#312991eb91791ad706f038d6a8383c63:be712621cf2b2bb3dfabbbfedf4c2b102294b18a, libev/4.33#8fc921587a3733e276520386c84ac583:5e6e38e5a54ca49246fc1eefcd6700d1d71fa40f

This means that the existing package binary was created with some "package_id_mode" like full_mode. This can happen because some external configuration, like the core.package_id:default_non_embed_mode, but also because some package changed the package_type, or modified its package_id.

Yet we can see above that hiredis 1.1.0 is same as 1.1.Z and libev 4.33 should be treated same as 4.33.Z but apparently it is not.explains

What the conan graph explain displays should be an exact match. Only 1.1.Z matches 1.1.Z, it doesn't match 1.1.0#rev. Those factors are not version ranges or semver versions, the values are hashed as they are to compute the package_id.

[hpe-ykoehler]

I am unclear how you got from the output to "package_id_mode", and why would not the explain output also mention that?

I am not sure I get where the 1.1.Z (the Z?) where it comes from, and even less why it is "expected". We certainly do not use that in our version.

Somehow the explanation given by conan graph explain is raising more question than answers.

[hpe-ykoehler]

Found more information here: https://github.com/conan-io/conan/issues/16161

Will explore if the shared option changes or transitive flags, yet I still don't get where the Z comes from, why it is displayed and what is means.

[memsharded]

This is explained in https://docs.conan.io/2/reference/binary_model/dependencies.html, you can see for example how https://docs.conan.io/2/reference/binary_model/dependencies.html#non-embed-mode explains the mapping to the .Z.

[hpe-ykoehler]

Thanks I think this help clarified things, I do wish it was more obvious in the conan graph explain output.

Wouldn't there be a way to preserve the profile and the requires() attributes used to build a binary cache as to enable comparison on such failure to then be able to pinpoint changes in options (shared/static) or transitive aspect?

Being able to say:

dependencies option mismatch 
  cached options:
    ...
  requested options:
    ...

 dependencies require flags mismatch
   cached flags
     ...
    requested flags
     ...

would be a lot more useful