diff options
author | Greg Becker <becker33@llnl.gov> | 2021-09-13 14:25:48 -0700 |
---|---|---|
committer | GitHub <noreply@github.com> | 2021-09-13 15:25:48 -0600 |
commit | dad69e7d7cc1f2d59e7288cc614dba6cc0c9daab (patch) | |
tree | 34cb1ee9d01eed36e2dd2baa1ae8056f42aad096 /bin | |
parent | 995684133124f70365ef326fdf5b64d649218ca7 (diff) | |
download | spack-dad69e7d7cc1f2d59e7288cc614dba6cc0c9daab.tar.gz spack-dad69e7d7cc1f2d59e7288cc614dba6cc0c9daab.tar.bz2 spack-dad69e7d7cc1f2d59e7288cc614dba6cc0c9daab.tar.xz spack-dad69e7d7cc1f2d59e7288cc614dba6cc0c9daab.zip |
Fix environment reading from lockfile to trust written hashes (#25879)
#22845 revealed a long-standing bug that had never been triggered before, because the
hashing algorithm had been stable for multiple years while the bug was in production. The
bug was that when reading a concretized environment, Spack did not properly read in the
build hashes associated with the specs in the environment. Those hashes were recomputed
(and as long as we didn't change the algorithm, were recomputed identically). Spack's
policy, though, is never to recompute a hash. Once something is installed, we respect its
metadata hash forever -- even if internally Spack changes the hashing method. Put
differently, once something is concretized, it has a concrete hash, and that's it -- forever.
When we changed the hashing algorithm for performance in #22845 we exposed the bug.
This PR fixes the bug at its source, but properly reading in the cached build hash attributes
associated with the specs. I've also renamed some variables in the Environment class
methods to make a mistake of this sort more difficult to make in the future.
* ensure environment build hashes are never recomputed
* add comment clarifying reattachment of env build hashes
* bump lockfile version and include specfile version in env meta
* Fix unit-test for v1 to v2 conversion
Co-authored-by: Massimiliano Culpo <massimiliano.culpo@gmail.com>
Diffstat (limited to 'bin')
0 files changed, 0 insertions, 0 deletions