Answer to the Core Question
Spack’s concretizer treats a variant that does not exist in the package definition as a hard error. The message
unsupported variant 'mpi' for package 'hdf5' means the spec contains a name that Spack cannot match. The
concretizer does not automatically fall back to an external MPI implementation unless the user explicitly
enables that behaviour. Enabling it by default would break reproducibility guarantees, because the same
spec could resolve to different MPI libraries on different machines or at different times.
Why the Error Appears
- Wrong syntax: The variant is declared as
+mpi, not just mpi.
- Case sensitivity:
+MPI or +Mpi are not recognised.
- Custom package: A forked or modified
hdf5 may have removed the +mpi variant.
Verify Available Variants
# Show the variants that the current Spack installation knows for hdf5
spack info hdf5
Look for a line such as:
variants: +mpi +debug +shared …
Correct the Spec
# Use the proper syntax with the leading plus sign
spack concretize -f hdf5+mpi
If this succeeds, the issue was purely a syntax mistake. If it still fails, inspect the local package
definition.
Check for a Custom Package
# Inspect the file that Spack is actually using
cat ~/.spack/packages/hdf5/package.py
Confirm that the file contains a line like:
variant('mpi', default=False, description='Build with MPI support').
If not, either install the official package or add the variant yourself.
When to Consider Relaxing Variant Constraints
Automatic relaxation can be useful in exploratory environments where the exact MPI implementation is
irrelevant. However, it should only be enabled when:
- The user explicitly opts in (e.g., via a config flag).
- The package still defines the variant name; unknown variants should not be silently ignored.
- The concretizer can verify that the external MPI satisfies the package’s requirements (compiler, ABI).
- The chosen MPI implementation is deterministic and recorded in the spec hash to preserve reproducibility.
To enable this behaviour in a controlled way, add the following to ~/.spack/config.yaml:
concretizer:
allow_unknown_variants: true
Use this setting sparingly and document its impact on your build pipelines.
Impact on Existing Workflows
- Specs that previously failed will now succeed, but the resulting binaries may differ across
machines if different MPI libraries are chosen.
- CI pipelines that rely on exact spec hashes may need to be updated to account for the new
dependency resolution.
- Package authors may need to add documentation explaining the relaxed behaviour.
Follow‑up Question
To tailor the recommendation further, could you confirm whether you are using the official Spack
hdf5 package or a custom fork that might have altered the variant list?