[bug] dependency resolution of header-only library is non-deterministic

[spektrof]

Hi,

We'd like to have a deterministic dependency resolution process where we can get exactly the same transient dependencies what we used at building for the given package.

We are using the name/version@#revision:package_id as an input with the following conan configuration:

[general]
default_profile = default
compression_level = 9
sysrequires_sudo = True
request_timeout = 60
default_package_id_mode = package_revision_mode
parallel_download = 8
revisions_enabled = 1
full_transitive_package_id = 1

The package_revision_mode and full_transitive_package_id will provide us a fully deterministic binary model. However I noticed some non-deterministic result with header-only packages.

Let's say we have a package (pkgC) which depends on pkgB header only library and pkgB depends on pkgA header only library. We build these packages, upload to the artifactory. Then later, the recipe of pkgA has been changed, so we decide to rebuild pkgB and pkgC. This case the built pkgB is different, but actually it has the same reference and cause problems.

The pkgB has the same reference because the requires field is empty. The full_requires field list the name/version:package_id for each dependency, but this is not enough to get the proper revision of pkgA, and the output of conan lock create will be different after the rebuild.

The requires field of pkgC is correct, it's package id will be different after the second build as it's expected.

Environment Details (include every applicable attribute)

• Operating System+version: RHEL7
• Compiler+version: g++ (GCC) 8.2.1 20180905
• Conan version: 1.48.1
• Python version: 3.7.5

Steps to reproduce (Include if Applicable)

Instead of checking the lockfile, I provide an example where we can see that the pkgB was generated with the same reference, however it's dependency is different after the second build. I used a metadata conan generator to check that.

Set up conanfiles, generator, patch file:

recipes/pkgA/conanfile.py

from conans import ConanFile

class PkgA(ConanFile):
  name = "pkgA"
  settings = "os", "arch", "compiler"

  def package_id(self):
    self.info.header_only()

  def package_info(self):
    self.cpp_info.name = "pkgA"
    self.cpp_info.components["pkgA_lib"].name = "pkgA_lib"
    self.cpp_info.components["pkgA_lib"].includes = ["include"]
    self.cpp_info.components["pkgA_lib"].defines = ["PKGA_PUBLIC_DEFINE"]

recipes/pkgB/conanfile.py

from conans import ConanFile

class PkgB(ConanFile):
  name = "pkgB"
  settings = "os", "arch", "compiler"
  requires = "pkgA/1.0"

  def package_id(self):
    self.info.header_only()

  def package_info(self):
    self.cpp_info.name = "pkgB"
    self.cpp_info.components["pkgB_lib"].name = "pkgB_lib"
    self.cpp_info.components["pkgB_lib"].includes = ["include"]
    self.cpp_info.components["pkgB_lib"].requires = ["pkgA::pkgA_lib"]

recipes/pkgC/conanfile.py

from conans import ConanFile

class PkgC(ConanFile):
  name = "pkgC"
  settings = "os", "arch", "compiler", "build_type"
  requires = "pkgB/1.0"

  def package_info(self):
    self.cpp_info.name = "pkgC"
    self.cpp_info.components["pkgC_lib"].name = "pkgC_lib"
    self.cpp_info.components["pkgC_lib"].requires = ["pkgB::pkgB_lib"]

recipes/patches/pkgA.patch

--- a/recipes/pkgA/conanfile.py
+++ b/recipes/pkgA/conanfile.py
@@ -10,3 +10,4 @@ class PkgA(ConanFile):
     self.cpp_info.name = "pkgA"
     self.cpp_info.components["pkgA_lib"].name = "pkgA_lib"
     self.cpp_info.components["pkgA_lib"].includes = ["include"]
+    self.cpp_info.components["pkgA_lib"].defines = ["PKGA_PUBLIC_DEFINE"]

generator/conanfile.py

from conans.model import Generator
from conans.model.conan_generator import GeneratorComponentsMixin
from conans import ConanFile


class metadata(Generator, GeneratorComponentsMixin):
  name = "metadata-generator-impl"

  @property
  def filename(self):
    return "metadata.json"

  @property
  def content(self):
    metadata = ""
    for pkg_name, tmp in self.deps_build_info.dependencies:
        cpp_info = self.deps_build_info.__getitem__(pkg_name)
        if cpp_info:
            self._validate_components(cpp_info)
            components = self._get_components(cpp_info.name, cpp_info)
            components = [component_cpp_info for _, component_cpp_info, _ in components]
            for component in components:
                metadata += f"name={component.name}\tdefines={component.defines}\n"
    return metadata

class MetadataGenerator(ConanFile):
  name = "metadata-generator"

conanfile.txt

[requires]
pkgB/1.0@
[build_requires]
metadata-generator/1.0

Steps:

$ conan config set general.default_package_id_mode=package_revision_mode 
$ conan config set general.full_transitive_package_id=1 
$ conan config set general.revisions_enabled =1

# first build:
$ # clear conan cache

$ conan create generator 1.0@
$ conan export recipes/pkgA 1.0@
$ conan create recipes/pkgA 1.0@ --profile=gcc82
$ conan get --raw pkgA/1.0@#6c2fca0730865fbf57482deb43c9062f:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9

$ conan export recipes/pkgB 1.0@
$ conan create recipes/pkgB 1.0@ --profile=gcc82
$ conan get --raw pkgB/1.0@#123809c765b8bad4dfc8505b052a4103:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 | sha256sum

$ conan export recipes/pkgC 1.0@
$ conan create recipes/pkgC 1.0@ --profile=gcc82
$ conan get --raw pkgC/1.0@#1d3807edca2b13ae6dccb1f91e5b07b3:3bdd940f0c25858757b4e9abda69765a09365e0d

$ conan install conanfile.txt --generator metadata --profile gcc82 --install-folder first/

# second build:
$ # clear conan cache

$ patch -i $(pwd)/recipes/patches/pkgA.patch -d recipes/pkgA --force

$ conan create generator 1.0@
$ conan export recipes/pkgA 1.0@
$ conan create recipes/pkgA 1.0@ --profile=gcc82
$ conan get --raw pkgA/1.0@#710ff3b2e7fcf71167b8b7a9ba020df8:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9

$ conan export recipes/pkgB 1.0@
$ conan create recipes/pkgB 1.0@ --profile=gcc82
$ conan get --raw pkgB/1.0@#123809c765b8bad4dfc8505b052a4103:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9 | sha256sum

$ conan export recipes/pkgC 1.0@
$ conan create recipes/pkgC 1.0@ --profile=gcc82
$ cconan get --raw pkgC/1.0@#1d3807edca2b13ae6dccb1f91e5b07b3:55f61778153282d366ef98c2abd4a9f01653ea4c

$ conan install conanfile.txt --generator metadata --profile gcc82 --install-folder second/

$ diff first/metadata.json second/metadata.json

Result:

pkgC:

The requires field of pkgC was correct:

# firstly built
[requires]
pkgA/1.0#6c2fca0730865fbf57482deb43c9062f:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9#ecba8fbd8681f38474db4111a4d63dbc
pkgB/1.0#123809c765b8bad4dfc8505b052a4103:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9#be0bcfd43bd2b86ebd3f1c797edcda72

# secondly built
[requires]
pkgA/1.0#710ff3b2e7fcf71167b8b7a9ba020df8:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9#af49baea296039974f542fbe69036ca2
pkgB/1.0#123809c765b8bad4dfc8505b052a4103:5ab84d6acfe1f23c4fae0ab88f26e3a396351ac9#be0bcfd43bd2b86ebd3f1c797edcda72

pkgB:

705e3e6e36f8192c0cb62a620ea783eafe95b627c4b7a984ef2e203fdbebaa60   # sha256sum for firstly built B
705e3e6e36f8192c0cb62a620ea783eafe95b627c4b7a984ef2e203fdbebaa60   # sha256sum for secondly built B

2c2 # diff
< name=pkgA_lib defines=[]
---
> name=pkgA_lib defines=['PKGA_PUBLIC_DEFINE']

As we can see the reference of pkgB was the same, however the secondly built pkgA has an additional defines which can change the behaviour of that library. Picking up the latest pkgA silently (if our project depends on pkgB directly and not depending on pkgC) is not acceptable for us.

Is there a way to prevent these scenarios?

[memsharded]

Hi @spektrof

First I would like to give some quick general feedback that might help to keep moving forward and be 2.0 ready:

• Using components in header-only libraries is probably useless, and adding extra complexity that is not serving any purpose. I recommend not using components except for compiled libraries and only when link times or issues appear
• Start calling your packages with all lowercase, as ConanCenter has been doing since a long time. Packages will be all lowercase in 2.0
• The self.cpp_info.name = "pkgC" is intended mostly for open-source packages that have an existing convention for CMake target names. For your own libraries is not recommended at all.
• You don't need to conan export recipes/pkgB 1.0@ before doing a conan create, as the first step the conan create does is an conan export.
• You might want to start considering using the generate() method and python requires to provide your own extensions instead of those custom generators syntax that is being removed in 2.0. The implementation of the logic should use self.dependencies and not self.deps_build_info nor self.deps_cpp_infoo.

If you have questions, need help or advice regarding this, do not hesitate to open new tickets and we will try to help.

Regarding the automatic resolution to latest revisions. This is how revisions work. A revision is the equivalent to a version range that always resolve to latest:

• If you had your pkg_b with a requires = "pkg_a/[>=1.0]", and then when you are introducing a change in pkg_a you create a new version that bumps from the previous 1.0 (without the define), to the new 1.1 (with the define), then you shouldn't be surprised that when you require pkg_b, it will pull in the dependency graph the new pkg_a/1.1, because that was exactly the constraint that was encoded in the recipe
• Revisions work in the same way, but implicitly. Lets say that the pkg_b requires = "pkg_a/10" is totally equivalent to requires = "pkg_a/1.0#latest. Then creating a new revision for pkg_a will be automatically pulled in the dependency graph in the same way a new version gets pulled in a valid version range.

To avoid this, there are different mechanisms to fix and constraint that:

• Use versioning: If you do a change in pkg_a, that you don't want to be automatically used by downstream consumers, bump its version,and consumers will need to explicitly update their requires to start using this new version.
• The pkg_b requires can perfectly explicitly pin down the revision they want to use: requires = "pkg_a/1.0#6c2fca0730865fbf57482deb43c9062f. The only issue with this approach is that if pkg_a is required also by other packages in the graph, all of them should pin the same revision, otherwise that will create version conflicts in the same way that if different packages were requiring pkg_a/1.0, pkg_a/2.1, pkg_a/3.4, etc.
• Using lockfiles for the first step, and then using that lockfile and providing it to install and create commands, so they guarantee that the new revision is not used in the graph. It is true that lockfiles can be a bit challenging in Conan 1.X to master, we have done a great effort in Conan 2.0 to simplify their usage

Also, I would like to highlight that this is not a "package_id" issue. The header-only libraries, no matter what happens or what dependencies they have, they will always result in the exact same set of headers, with exactly the same checksum, so they always result in the same package_id. The behavior is before resolving the binaries, it is about resolving the "recipe" revision (and version), not the binary artifacts.

Please let me know if this clarifies it a bit.

[spektrof]

Hi @memsharded ,

Thanks for your reply!

We definitely need to check Conan 2.0 but we cannot really use that until it's an alpha release. I will discuss it with my team.

Currently our aim is to build any 3rdparty libraries which are available in the conan-center-index, upload them to the artifactory, so other users can consume the same package and having reproducible builds with conan dependencies. We are not at that stage yet where we want to create recipes to our projects. I played a bit with custom recipes to see how the revision and package id is changing based on the configuration.

You might want to start considering using the generate() method

We are using an other custom generator to generate a metadata file what we use to generate other files. The same method should be applied to every package. Now, if a 3rdparty library does not have this generate() method or we need a different one, can we apply a custom generator function in Conan 2.0?

when you are introducing a change in pkg_a you create a new version that bumps from the previous 1.0 (without the define), to the new 1.1 (with the define)

Does conan-center-index guarantee that those packages which upgraded their recipe only (e.g. change package_info() method), will increase the minor/patch version?
If yes, then we have nothing to worry about.
If no, then is it the owner's fault by not updating the version?

For me, a change, which is not related to the source-code should have the same version and should be handled by the package manager. Maybe I am wrong, or at least that would be easier if I am wrong.

I have further questions regarding the reproducible builds.

As I read in the documentation, we need to have lockfiles which will lock the configuration, therefore will always get the same dependencies. As you mentioned, generating a lockfile is quite challanging because I need to know the revision and configuration of each transitive dependency.

How do you provide reproducible builds if you uploaded the packages to the artifactory, right after you built them?

As far as I know, lockfiles cannot be uploaded. So let's say we build the packages in CI and upload them. As a consumer, I know my direct dependencies (list of name/version#revision:package_id), know the artifactory remote where I can download the packages from, can I generate the same lockfile, by knowing these package references, than what I had at build time?
Based on my local tests, using package_revision_mode is good enough for binary packages, but not for header-only ones.

The header-only libraries, no matter what happens or what dependencies they have, they will always result in the exact same set of headers, with exactly the same checksum, so they always result in the same package_id

Does this mean that I cannot guarantee the reproducible build if I depend on a header only library, unless I know the revision of it's dependencies?

[memsharded]

We definitely need to check Conan 2.0 but we cannot really use that until it's an alpha release. I will discuss it with my team.

Sure, you don't need to jump to Conan 2.0. Most of the tools that you need to be ready for 2.0 are already available in Conan 1.X. The migration guide in https://docs.conan.io/en/latest/conan_v2.html, describe many of those things that need to be taken into account (Conan 2.0 beta is probably being released tomorrow)

Currently our aim is to build any 3rdparty libraries which are available in the conan-center-index, upload them to the artifactory, so other users can consume the same package and having reproducible builds with conan dependencies. We are not at that stage yet where we want to create recipes to our projects. I played a bit with custom recipes to see how the revision and package id is changing based on the configuration.

This is totally fine, and the majority of users are actually storing their packages in their own private servers, instead of using ConanCenter in production. This is a good practice, for other languages package managers too. Then, users vary their usage of ConanCenter resources, some will do a direct copy, others will build from source but recipes are exactly the same one (but they have policies they cannot use external binaries), and other users will fork, customize and fine tune the recipes to their specific needs.

We are using an other custom generator to generate a metadata file what we use to generate other files. The same method should be applied to every package. Now, if a 3rdparty library does not have this generate() method or we need a different one, can we apply a custom generator function in Conan 2.0?

Yes, the steps are putting that generator (that does not need to extend any base class) in a conanfile.py, then in the pakage recipes that want to use that generator use python_requires to that package and instantiate the generator explicitly in your generate() method. It requires 2 more lines than the previous one, but it is a much better approach, because for example, generators can be versioned, and their effect on the package_id controlled: if you do a minor change to your generator and don't want that to force a rebuild of the consumers, you can just bump the patch version. If you want to trigger a re-build of packages using that generator, then you can bump the minor version of the package containing the generator code, and it will work.

Does conan-center-index guarantee that those packages which upgraded their recipe only (e.g. change package_info() method), will increase the minor/patch version?
If yes, then we have nothing to worry about.
If no, then is it the owner's fault by not updating the version?

the community around ConanCenter together with the maintainers got to the consensus that versions in ConanCenter need to match the "upstream" base source version. So the ConanCenter package boost/1.76.0 should match exactly the boost 1.76.0 release, and viceversa. Then, pure recipe changes, without changing the source code, do not create new versions, but instead create new recipe revisions. This happens regularly, for example, when someone is using a given package and wants to cross-build it for some embedded, Android, or whatever, then realize that something is necessary in the recipe to support that case, and doing a PR for it. It will not affect all other platforms, but still a new recipe revision is obtained. It doesn't make sense to bump it to boost/1.76.1 because the Conan recipe had a fix to support Android, as it will diverge from the 1.76.0 original source code tag.

For me, a change, which is not related to the source-code should have the same version and should be handled by the package manager. Maybe I am wrong, or at least that would be easier if I am wrong.

Exactly, this is what is happening. This is handled by the package manager, and the policy is to obtain by default the latest revision, because a change in an existing recipe is always considered a fix, something that you want to automatically upgrade to, because it is not that some C++ api code changed, it is the equivalent of doing some fixes to the build scripts of that dependency.

As I read in the documentation, we need to have lockfiles which will lock the configuration, therefore will always get the same dependencies. As you mentioned, generating a lockfile is quite challanging because I need to know the revision and configuration of each transitive dependency.

No, they are challenging because of other reasons. Capturing a lockfile with all the revisions, including the transitive requirements revisions is automatic and relatively easy, just a conan lock create .... command (with same arguments as a create or install)

How do you provide reproducible builds if you uploaded the packages to the artifactory, right after you built them?

An usual approach is to store them somewhere else, like in another git repo or in an Artifactory generic repo. Typically it is a bit more dev-friendly to use a git repo.

As far as I know, lockfiles cannot be uploaded. So let's say we build the packages in CI and upload them. As a consumer, I know my direct dependencies (list of name/version#revision:package_id), know the artifactory remote where I can download the packages from, can I generate the same lockfile, by knowing these package references, than what I had at build time?
Based on my local tests, using package_revision_mode is good enough for binary packages, but not for header-only ones.

Lockfiles in general, also in other languages, work in a slightly different way. You first capture the lockfile, as a snapshot of the dependencies, typically at install time. Then use that lockfile when you are developing to keep deps locked. And finally upload the packages and store that lockfile that you have been using along the process. But not capturing a lockfile after things have been built.

Based on my local tests, using package_revision_mode...

This is not accurate. The reproducibility scenario that you are describing happens much earlier, when the dependency graph is computed. Only after the full dependency graph, with recipe versions, recipe revisions, and configuration is fully computed, the package binaries package_id is computed. This is the place where the package_revision_mode enters. (Btw, package_revision_mode has been removed in Conan 2.0 because of complex and unnecessary. For being "safe", recipe_revision_mode should be good).

[spektrof]

Hi @memsharded ,

Thank you for some clarifications and suggestion about how to move to Conan 2.0.

Btw, package_revision_mode has been removed in Conan 2.0 because of complex and unnecessary. For being "safe", recipe_revision_mode should be good

It's good to know, thank you!

No, they are challenging because of other reasons. Capturing a lockfile with all the revisions, including the transitive requirements revisions is automatic and relatively easy, just a conan lock create .... command (with same arguments as a create or install)

I disagree with this, if I want to consume a package from the artifactory, and run a lock create without knowing the revisions / configurations, it will generate a wrong, in some cases unusable lockfile. Also, based on your policy, it will generate a different lockfile time to time because it will pick the latest revision.
So basically I need to get the revision:package_id information of transitive dependencies from the direct dependencies - which are uploaded to the artifactory and match the same configuration when I uploaded them -, before I can start to generate new lockfiles, which is not a problem, if we can do that. My only problem right know is the header-only libs.

But not capturing a lockfile after things have been built.

This is true because in your case, you stored the lockfile what was used at the building, so if someone wants to consume your package later, can pick up your lockfile too.

the policy is to obtain by default the latest revision, because a change in an existing recipe is always considered a fix, something that you want to automatically upgrade to, because it is not that some C++ api code changed, it is the equivalent of doing some fixes to the build scripts of that dependency.

This means that your policy "breaks" the reproducibility (because of the automatic upgrades), unless we have the initial lockfile what we used for building.
In our case we wrote some scripts around our project which is using the output of the custom generator. This means that if the recipe changes, then the output of the script can be different, so we don't want any automatic upgrades.

Can this policy be changed in the configuration?

An usual approach is to store them somewhere else, like in another git repo or in an Artifactory generic repo. Typically it is a bit more dev-friendly to use a git repo.

Well, this sounds odd to me, but if we won't have any other choices then we need to do this. I would expect that if I upload something to the artifactory, then I can download that with the same set of dependencies (without any pre-stored lockfile).

[memsharded]

I disagree with this, if I want to consume a package from the artifactory, and run a lock create without knowing the revisions / configurations, it will generate a wrong, in some cases unusable lockfile. Also, based on your policy, it will generate a different lockfile time to time because it will pick the latest revision.

But this is not how lockfiles are used. Of course if you generate a new lockfile later in time it can resolve to a different set of revisions. Lockfiles are snapshots in time of a dependency graph. If you create snapshots in different points in time, you can get different results. This is how lockfiles work in all other package managers too. The point of a lockfile is not that your repository cannot change and dependencies cannot evolve, but that you can use the same set of dependencies that you captured in a lockfile some time ago. To maintain things in a good state in the repositories, you typically start with a lockfile, then build, test, finally upload those things to the Artifactory (running a promotion of packages from one build repo to the develop repo, to keep the develop repo in a consistent state). If you want to keep those dependencies locked, you keep using that lockfile. If you want to upgrade and start using latest revisions, then you create a new lockfile, build and test with it, and if everything looks good, you promote it to become the latest packages in your Artifactory repo.

I think you are looking for this: #10261

It is a mechanism to put the lockfiles together with the recipes, to be used while retrieving the package from the server.
This is just very early experimentation stage for several reasons:

• The basic functionality of lockfiles has to be stabilized first, and importantly the lockfile model and file storage. Because once you start putting lockfiles as part of the packages, it is super complicated to evolve and fix things without breaking
• So at the moment we are at the equivalent stage of package-lock.json in NPM. You can create lockfiles and store them in your side, but those files are not part of the packages and wont be used.
• The above PR is somehow close to the shrinkwrap (https://docs.npmjs.com/cli/v8/commands/npm-shrinkwrap) NPM functionality. Note how they don't even recommend to use this approach for regular libraries, because it is problematic for development.

Well, this sounds odd to me, but if we won't have any other choices then we need to do this. I would expect that if I upload something to the artifactory, then I can download that with the same set of dependencies (without any pre-stored lockfile).

This is not odd, up to my knowledge this is how the majority of package managers, also for other languages, work. This is the same concept as the example with version ranges above requires = "pkg_a/[>=1.0]". If the requires definitions are not constrained, they will freely evolve to resolve to the latest published versions or revisions. If you don't want them to evolve, then the options are 1) fully specify the requires definition or 2) use lockfiles.

It seems that in your case, if you want that level of determinism and using lockfiles suppose an unnecessary burden (one of their purpose is to enable CI at scale, but that doesn't seem your concern right now) the right approach would be to specify your requires down to the recipe revision. There is nothing wrong in that approach, it seems what you want, why not just specifying the revisions that you want in your recipes requires?

[jcar87]

Hi @spektrof -

As @memsharded has mentioned, I believe what you are experiencing is the "expected" behaviour given how the recipes are configured.

In particular, looking at your conanfile.py for pkgB:

  requires = "pkgA/1.0"

  def package_id(self):
    self.info.header_only()

You are describing the following situation:

Let's say we have a package (pkgC) which depends on pkgB header only library and pkgB depends on pkgA header only library. We build these packages, upload to the artifactory. Then later, the recipe of pkgA has been changed, so we decide to rebuild pkgB and pkgC. This case the built pkgB is different, but actually it has the same reference and cause problems.

According to the documentation for self.info.header_only() (link here):

The package will always be the same, irrespective of the settings (OS, compiler or architecture), options and dependencies.

This means that in the recipe for pkgB, by calling that method we are telling conan to not factor changes in the dependencies for computing the package ID, and in this the case the same recipe revision for pkgB will not result in new package ID if a newer revision for pkgA exists.

As @memsharded mentions, one way of solving this is to bump the version of pkgA when you change its recipe (some changes do warrant a version of bump), which would require you to reflect it in pkgB.
However, if you are in a situation where pkgB is header only, but would result in a different package if pkgA (also header only), changes in some way, then the condition expressed for the self.info.header_only() documentation no longer holds true: in this case, we would need the package ID to reflect the dependencies as well.
This really does depend on how pkgB is constructed, however, you could try and tweak the package_id() method for pkgB such that it doesn't remove the dependencies from the package ID. You're still likely to want to remove options and settings that do not influence the resulting package, such as os/compiler, etc.

[spektrof]

Hi @memsharded , @jcar87 ,

Thanks for your replies and clarifications.

I think you are looking for this: #10261

Exactly, this looks good to me.

why not just specifying the revisions that you want in your recipes requires?

I want to keep building the packages with the latest recipes in CI and upload them to the artifactory, but I don't want to consume them automatically, so I don't want to lock the revisions in recipes because that would be an unnecessary work.

According to the documentation for self.info.header_only() (link here):

Currently, I only want to build the packages from the conan-center-index, this was only an example to play with, and I am thinking about whether this scenario can happen if I build packages or not. Is it the owner's fault or not.

Based on the documentation and your clarifications I think it can happen and not the owner's fault, because they might want to pick the latest pkgA changes automatically.

The version bumping is not good choice, because recipe only changes is not a source code change.

I will think about how can I store the lockfiles what we use at building, and plan to move to Conan 2.0.

[spektrof]

Hi,

I checked some possibilities what you suggested and I have:

1) specifying revisions in recipe:
I can differentiate the packages in that case, however it's complicated to do that because I would have to patch the recipes from leaf nodes to the root node in the dependency tree. In addition the revision would be always different, no matter what kind of changes has been made on a recipe.

2) uploading and using lockfiles:
It would work, however also complicates the workaround at my header-only scenario a bit because the package reference of pkgB would be the same, so I would have some "naming issue".

3) ignore package_id()
Using the default package id calculation mode is good for us, so I considered to remove the package_id() method from the recipes when build a package. This is working as I expected, so I might choose this way.

Later on, when we upgrade to Conan 2.0, we will check how #10261 is going, what I am really looking forward to.

Thank you for the help!

[memsharded]

leaf nodes to the root node in the dependency tree. In addition the revision would be always different, no matter what kind of changes has been made on a recipe.

Yes, but this is the price to pay for full determinism. If you want to ensure the upstream dependency is identical, you can only compare the contents hash. If something changed in the recipe, it could be from something irrelevant with no effect, or an important change that affects how the package is built. But that is impossible to know automatically, so if determinism is wanted, it should be considered that every change in a recipe is relevant.

Thanks to you for the feedback! As there is no action we can take for this, beyond what is already in #10261, I think this issue can be closed, but feel free to re-open or submit a new one if you have further questions!