How the `package_id` is computed¶

Let’s take some package and list its binaries, for example:

$ conan list "zlib/1.2.13:*" -r=conancenter
Local Cache
  zlib
    zlib/1.2.13
      revisions
        97d5730b529b4224045fe7090592d4c1 (2023-08-22 02:51:57 UTC)
          packages
            d62dff20d86436b9c58ddc0162499d197be9de1e  # package_id
              info
                settings
                  arch: x86_64
                  build_type: Release
                  compiler: apple-clang
                  compiler.version: 13
                  os: Macos
                options
                  fPIC: True
                  shared: False
            abe5e2b04ea92ce2ee91bc9834317dbe66628206  # package_id
              info
                settings
                  arch: x86_64
                  build_type: Release
                  compiler: gcc
                  compiler.version: 11
                  os: Linux
                options
                  shared: True

We can see several binaries for the latest recipe revision of zlib/1.2.13. Every binary is identified by its own package_id, and below it we can see some information for that binary under info. This information is the one used to compute the package_id. Every time something changes in this information, like the architecture, or being a static or a shared library, a new package_id is computed because it represents a different binary.

The package_id is computed as the sha1 hash of the conaninfo.txt file, containing the info displayed above. It is relatively easy to display such file:

$ conan install --requires=zlib/1.2.13 --build=missing
# Use the <package-id> listed in the install
$ conan cache path zlib/1.2.13:<package-id>
# cat the conaninfo.txt in the returned path
$ cat <path>/conaninfo.txt
[settings]
arch=x86_64
build_type=Release
compiler=msvc
compiler.runtime=dynamic
compiler.runtime_type=Release
compiler.version=193
os=Windows
[options]
shared=False
$ sha1sum <path>/conaninfo.txt
# Should be the "package_id"!

The package_id is the sha1 checksum of the conaninfo.txt file inside the package. You can validate it with the sha1sum utility.

If now we have a look to the binaries of openssl we can see something like:

$ conan list "openssl/3.1.2:*" -r=conancenter
conancenter
  openssl
    openssl/3.1.2
      revisions
        8879e931d726a8aad7f372e28470faa1 (2023-09-13 18:52:54 UTC)
          packages
            0348efdcd0e319fb58ea747bb94dbd88850d6dd1  # package_id
              info
                settings
                  arch: x86_64
                  build_type: Release
                  compiler: apple-clang
                  compiler.version: 13
                  os: Macos
                options
                  386: False
                  ...
                  shared: True
                requires
                  zlib/1.3.Z

We see now that the conaninfo.txt contains a new section the requires section. This happens because openssl depends on zlib, and due to the C and C++ compilation model, the dependencies can affect the binaries that use them. Some examples are when using inline or templates from #include header files of the dependency.

Expanding the image above:

As it can be seen, even if the settings and the options are the same, different binaries will be obtained if the dependencies versions change. In the next section how the versions affect the package_id is explained.

How the package_id is computed¶

How the `package_id` is computed¶