[bug] Faulty package-id comparison for build_requires when using lockfiles

The problem occurs when trying to build a build requirement C from a lock file with the “–build-require” argument provided and using a dependency graph like this

A.requires(B) A.build_requires©

B.requires©

C.requires(D)

This dependency graph results in a lockfile with two entries for C and D, each once in the host and once in the build context. But in graph_lock.py it will search only for the first occurence of a dependency reference in the lock graph which is in the host context. Later on, it will compare the package id of that node in the lock graph with the computed package_id which considers the --build-require context leading to an error stating that the package ids do not match.

Environment Details (include every applicable attribute)

• Operating System+version: Ubuntu 20.04
• Compiler+version: gcc 8
• Conan version: 1.51.0
• Python version: 3.8.10

Steps to reproduce (Include if Applicable)

see my minimal example

Logs (Executed commands with output) (Include/Attach if Applicable)

Expected output:

Using lockfile: '/home/sfr7ba/repos/conan_minimal_example2/deps_lockfile.lock'
Configuration (profile_host):
[settings]
arch=armv8.3
build_type=Debug
compiler=gcc
compiler.libcxx=libstdc++11
compiler.version=8
os=Linux
[options]
[build_requires]
[env]

Configuration (profile_build):
[settings]
arch=x86_64
build_type=Debug
compiler=gcc
compiler.libcxx=libstdc++11
compiler.version=8
os=Linux
[options]
[build_requires]
[env]

ERROR: 'sub_sub_package/1.0.0@test/test' package-id 'af0fbc5eb7376a4b9749db37a5c402b36d452909' doesn't match the locked one '8259f0ca51d6e5de1ae227eda55edb4a8cf7bcd2'

[memsharded]

Ok, I see now, thanks. The graph you are describing is slightly different to the one reflected in the test, still the problem would be the same, so the test captures the underlying issue, all good.

Bad news is that I have been trying for a couple of hours to fix this in 1.X and all I got is a couple of messy branches breaking more than they solve. I’ll keep you posted.

[memsharded]

I have tried again, put some good hours, still nothing reasonable that won’t break all…