Proposal: Pinning Hab Package Versions

[atrniv]

Currently the only way to pin a package version within a plan build is by explicitly specifying a complete package identifier of the form origin/name/version/release within the plan file. This presents a problem when we do native plan builds (because we don't get a fresh /hab/pkgs folder in native builds) or when we downgrade a version of a dependency (because the builder will have a newer version available).

I propose we introduce a new environment variable HAB_PIN_PKGS that changes the behaviour for of package identifier resolution within the hab binary.

• HAB_PIN_PKGS is a : separated list of complete package identifiers. Eg: HAB_PIN_PKGS=core/glibc/2.35/20230401230101:core/binutils/2.39/202304010230204

• Any identifier that could be satisfied by one of complete package identifiers in HAB_PIN_PKGS resolves to the complete identifier. Eg: core/glibc and core/glibc/2.35 would resolve to core/glibc/2.35/20230401230101 in this case.
  But core/glibc/2.35/20240101010101 and core/glibc/2.45 would resolve as before.

This solves the following problems:

• Native plan builds can work correctly when a version is downgraded without any change to the plan.sh file. This a major roadblock for automating MacOS builds with hab-auto-build since even studio based builds share the same /hab/pkgs directory, so changing plan versions while developing causes breakage of builds unless we manually clean up bad build results and partially installed packages from /hab/pkgs.
• We have the same problem with native builds on linux, but we solve that using Docker containers to create a fresh /hab/pkgs for every build.
• We can create deterministic reproducible studio builds by setting HAB_PIN_PKGS to the list of TDEPS and BUILD_TDEPS from the artifact we wish to reproduce. This could also be used to prevent potential breakages in CI systems due to an broken package release that was uploaded to the builder.