Description
When using HTTP binary caching with a URL template (e.g. http,https://cache.example.com/...), the current supported variables are only:
{name}{version}{sha}{triplet} (target triplet)
There is no {host-triplet} variable.
This causes significant cache conflicts in common cross-compilation and multi-architecture scenarios, especially on macOS.
Problem Details
For example:
On Apple Silicon Macs (arm64), the default host triplet is arm64-osx, on Intel Macs (x64), is x64-osx.
Both archs can cross compile binary for the other.
Host tools are built with the host triplet, the same port can produce two completely different binaries depending on the host triplet.
This issue also exists in other cross-compilation environments.
However, since the URL template can only use {triplet}, packages built for different host triplets end up at the same location. It is not sufficient or clean for organizing cache paths.
Without {host-triplet}, cache cleanup and retention policies become significantly more difficult.
Ideally, for a given (name, version, triplet), we only need to keep the latest build for each (host-triplet, triplet) combination.
Currently, because host information is not explicitly in the path, administrators cannot easily write retention rules (e.g. “keep only the latest package for each host+target pair”).
This leads to cache bloat, manual intervention, or overly aggressive pruning that accidentally deletes valid cache entries.
Using only {sha} is not a good solution because the hash is long, opaque, and not suitable for human-readable directory structures or simple retention policies.
Description
When using HTTP binary caching with a URL template (e.g. http,https://cache.example.com/...), the current supported variables are only:
{name}{version}{sha}{triplet}(target triplet)There is no
{host-triplet}variable.This causes significant cache conflicts in common cross-compilation and multi-architecture scenarios, especially on macOS.
Problem Details
For example:
On Apple Silicon Macs (arm64), the default host triplet is
arm64-osx, on Intel Macs (x64), isx64-osx.Both archs can cross compile binary for the other.
Host tools are built with the host triplet, the same port can produce two completely different binaries depending on the host triplet.
This issue also exists in other cross-compilation environments.
However, since the URL template can only use
{triplet}, packages built for different host triplets end up at the same location. It is not sufficient or clean for organizing cache paths.Without
{host-triplet}, cache cleanup and retention policies become significantly more difficult.Ideally, for a given (name, version, triplet), we only need to keep the latest build for each (host-triplet, triplet) combination.
Currently, because host information is not explicitly in the path, administrators cannot easily write retention rules (e.g. “keep only the latest package for each host+target pair”).
This leads to cache bloat, manual intervention, or overly aggressive pruning that accidentally deletes valid cache entries.
Using only {sha} is not a good solution because the hash is long, opaque, and not suitable for human-readable directory structures or simple retention policies.