To do release management as described in #7116 and #7117, we need to include the hash of package.py files in the spec, so that changes to builds are reflected in the Spack hash.

We have had logic to do this for a while, in the features/package-hash branch. This branch canonicalizes packages by removing comments, directive metadata, and unused version-specific @when decorators, then it hashes what's left and factors that into the spec.

We haven't worked this into Spack proper yet, because there needs to be additional support in the concretizer to make it less disruptive. But we'll at least need it to detect that packages have changed meaningfully since the last build.

• Rebase features/package-hash on develop and get it working. (Features/package hash #7193)

• Depending on whether the new concretizer is ready, decide whether to make the package hash part of the spec hash, or whether we should just use it for builds.

  • merge in appropriate support
  • Decision: we will just use this to detect builds for now. The support for full hashing is in place, but full hashing won't be in production until we have the new concretizer.

• ensure that binaries are rebuilt when changes are made to package.py files on a release branch, see Ensure that binaries are rebuilt when changes are made to package.py files on a release branch #8387 for discussion.