How the package_id is computed

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

  1. $ conan list "zlib/1.2.13:*" -r=conancenter
  2. Local Cache
  3.   zlib
  4.     zlib/1.2.13
  5.       revisions
  6.         97d5730b529b4224045fe7090592d4c1 (2023-08-22 02:51:57 UTC)
  7.           packages
  8.             d62dff20d86436b9c58ddc0162499d197be9de1e  # package_id
  9.               info
  10.                 settings
  11.                   arch: x86_64
  12.                   build_type: Release
  13.                   compiler: apple-clang
  14.                   compiler.version: 13
  15.                   os: Macos
  16.                 options
  17.                   fPIC: True
  18.                   shared: False
  19.             abe5e2b04ea92ce2ee91bc9834317dbe66628206  # package_id
  20.               info
  21.                 settings
  22.                   arch: x86_64
  23.                   build_type: Release
  24.                   compiler: gcc
  25.                   compiler.version: 11
  26.                   os: Linux
  27.                 options
  28.                   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.

../../_images/conan_package_id.png

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:

  1. $ conan install --requires=zlib/1.2.13 --build=missing
  2. # Use the <package-id> listed in the install
  3. $ conan cache path zlib/1.2.13:<package-id>
  4. # cat the conaninfo.txt in the returned path
  5. $ cat <path>/conaninfo.txt
  6. [settings]
  7. arch=x86_64
  8. build_type=Release
  9. compiler=msvc
  10. compiler.runtime=dynamic
  11. compiler.runtime_type=Release
  12. compiler.version=193
  13. os=Windows
  14. [options]
  15. shared=False
  16. $ sha1sum <path>/conaninfo.txt
  17. # 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:

  1. $ conan list "openssl/3.1.2:*" -r=conancenter
  2. conancenter
  3.   openssl
  4.     openssl/3.1.2
  5.       revisions
  6.         8879e931d726a8aad7f372e28470faa1 (2023-09-13 18:52:54 UTC)
  7.           packages
  8.             0348efdcd0e319fb58ea747bb94dbd88850d6dd1  # package_id
  9.               info
  10.                 settings
  11.                   arch: x86_64
  12.                   build_type: Release
  13.                   compiler: apple-clang
  14.                   compiler.version: 13
  15.                   os: Macos
  16.                 options
  17.                   386: False
  18.                   ...
  19.                   shared: True
  20.                 requires
  21.                   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:

../../_images/conan_package_id_full.png

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.