[bug] Conan 2.8.0 SHA1 differs from 2.7.1

[mzukovec]

Describe the bug

I'm using conan (Windows) in our production environment and the upgrade to the 2.8.0 fails to find one of the packages listed in conanfile.py due do different SHA1. We're using explicit revisions.

Explicit SHA1(Get-FileHash -Algorithm SHA1 conaninfo.txt) results in B692E48396E2CC29EE7048A4BE2DFDA907940859

Command:

Note that I'm using the same profiles and conanfile.py in both cases.

conan install . --profile default --profile:host wasm_Release --profile:build default

2.7.1 results in package:
vtk/7.1.1@xlab/wasm#7c3b7a01ee895d518cd31dfea7c6e5b3:b692e48396e2cc29ee7048a4be2dfda907940859

2.8.0 results in package:
vtk/7.1.1@xlab/wasm#7c3b7a01ee895d518cd31dfea7c6e5b3:e117c1d7a5f53b1e1b366d69168614542e4c3138

How to reproduce it

No response

[memsharded]

Hi @mzukovec

Thanks for your report.

I think it is very likely that this is the result of a bug fix in #16987

It seems there were cases in which the requires("dep/version", package_id_mode="xxxx") was being ignored, resulting in a buggy package_id, the bug fix in #16987 fixed it, but the result of applying the right package_id_mode is a new package_id that needs to be built.

You can follow some discussion about this that happened in #17086. If it is the same case, you should be able to see with conan list the previous (incorrect) package_id, and with Conan 2.8 you should see the correct one.

Can you please check that and let us know? Thanks for your feedback.

[mzukovec]

package_id_mode="urelated" is indeed the case of why this is happening. I'll migrate to the vendor=True as discussed in the issue that you linked.

[memsharded]

package_id_mode="urelated" is indeed the case of why this is happening. I'll migrate to the vendor=True as discussed in the issue that you linked.

Sounds good, if you really wanted to achieve that "decoupling" effect of the vendor=True feature with the unrelated mode. The important bit is to understand it is a trade-off between decoupling the dependencies of an application-like package that fully vendors the dependencies and getting the exact information of when that application-like package needs to be re-built from source because some of its dependencies changed (correct package_id computation with the correct package-id-mode (not unrelated)).

I'll leave the ticket open then, please let us know how it goes with the vendor=True feature.

[memsharded]

Hi @mzukovec

Any further feedback here? Did you try the vendor=True feature?

If not, I think we can close the issue as not a bug, as it was really a bugfix that affected some incorrectly created package-ids.

[mzukovec]

Hi @memsharded

After some investigation we decided that vendoring may not be an ideal option, so we rebuilt the packages with two conan versions in order to support compatibility with all versions.

I’ll keep it in mind though.

Thanks for your help and insights.

[memsharded]

Thanks to you for your feedback @mzukovec !

I am then going to close this ticket as resolved, but please re-open or create new tickets for any further question or issue you might have.