Proposal: Set manifest build_release to zero in binary manifests and leave it out in .jsonc manifests

[ermo]

Motivation

Manifests should only contain information that's shared and reproducible across binary moss-format repos; that is, any information that's related to the specific ABI + profile of a set of .stones in a binary repo is not relevant to the manifests.

The implication is that manifests should therefore contain only the "promise" for the installed artefacts and providers it will generate, plus the generically applicable dependency information that was used to build it (chiefly DT_NEEDED dynamically shared object name dependencies). This generically applicable dependency information is essentially expected to be identical across different build profiles for a given architecture, as the same library will expose the same DT_NEEDED and DT_SONAME fields, even if other properties in the shared object might differ (chiefly ABI, build-ids etc.). Note that a single manifest artefact specifically only applies to a single architecture family such as x86_64 with emul32 i386 fallback.

This way, a single recipe repository may be able to host recipes that are used to generate manifests and installable binary .stone artefacts for multiple different build profiles and architectures.

If we don't follow this path, manifests will be essentially useless when shared between different binary repos like, say, local repos on user or developer machines that may want to shadow upstream recipe repos, but where the local user also wants to change or tweak the upstream build profile for specific .stones for whatever reason.

More specifically, not following this path would make the build_release field + ABI info go out of sync between the upstream recipe repo vs. the actual .stone artefacts in the local binary moss-format repo just via the action of rebuilding the upstream recipe.

In contrast to generic manifest information, ABI properties for .stones are strongly specific to the actual set of surrounding providers and dependencies in the context of a single binary moss-format repository, and thus aren't even portable between different binary repository build profiles.

Therefore, the ABI properties themselves and their derived build_release field per .stone, should not be included in the manifests that get committed to the recipe repo as part of the "proof of build" process.

This implies that the build_release field is a field that should only get bumped in .stones based on machine-detected ABI mismatches when detecting what to rebuild. This implies that this field is only really relevant when deciding to do automated rebuilds in response to ABI-releated dependency checks within a specific binary moss-format repository w/associated default build profile.

This separation of concerns in turn enables downstream consumers to depend on update logic that checks if the installed .stone has a <= source_release field and then a < build_release field compared to what is available in the upstream binary moss-format index. This makes it possible to do the ABI checks on the binary repo side once per build plan operation, and then subsequently letting all consumers use the build_release field as a convenient substitution for having to do their own on-disk ABI sanity checks.

Actionable Proposal:

• For manifests: Set the build_release property to 0 in binary manifests, omit it in human-readable .jsonc manifests
• For .stones: Set the build_release property to >= 1 (with 1 being the default if no -bN argument is specified to boulder build

This ensures that the structure of manifests (which are essentially "scrubbed" .stone metadata) and .stones have the same format and can be read and manipulated using the same code path.

[ermo]

Resolved by #211