I'm still not sure why this was added. We need to double check if it was a performance fix, and if it is still needed. Given the type of checks, it's possibly related to the DB.

We also have an issue where we don't enforce having the package hash in the node dict correctly, not really sure what to do about this:

Basically, if a hash needs the package hash, but we don't have the attribute, we'll just skip it. This seems incorrect in general.

@haampie What do you think about #47975 (comment) ? In my opinion the right thing to do would be to store the provenance of the package hash, which could be:

1. Absent ("old" specs)
2. Read from specfile, etc. (computed once upon a time, should be considered a constant that is difficult to be re-computed again)
3. "Just" computed

The idea is that:

• Only case 1 should be allowed not to have a package hash.
• We probably never need to compute a hash for case 1 and 2, since we'll be reading the hash values from specfile
• Only case 3 should drop the cached hash values on a call to Spec.clear_caches, since for the other cases the values are just constant that we might not be able to re-compute with the current Spack

I wonder if it is worth to refactor in this sense, instead of doing what we do now (if an attribute is not there, assume we are dealing with an old spec format).