Default vs. Strict Concretizer for Complex Dependency Resolution

Spack utilizes a concretizer to transform abstract package specifications into a concrete build plan. When managing a complex Directed Acyclic Graph (DAG) of dependencies, there is a choice between the default concretizer and the strict concretizer.

The default concretizer explores a broad search space of versions and variants to find a globally compatible solution. In contrast, the strict concretizer restricts this search space to specific constraints to reduce resolution time and increase predictability.

The primary constraint is the balance between resolution speed and the likelihood of finding a valid solution in environments with highly restrictive version requirements. It is unclear how these two approaches behave when multiple dependencies require conflicting versions of the same package.

• Does the strict concretizer consistently fail in scenarios where the default concretizer would find a valid permutation?
• What is the impact on resolution stability when using the strict concretizer across different Spack versions?