add clarifications about concretization semantics

scheibelp · scheibelp · commit 41565f3c8b9b · 2021-05-27T14:30:29.000-07:00
diff --git a/seps/sep-0002.md b/seps/sep-0002.md
@@ -21,9 +21,9 @@ See also: https://github.com/spack/spack/discussions/22749
 ## Proposed Changes
 
 * Modify variant declarations with a flag to indicate that the variant
-  determines how the package is used rather than how it is installed
-* During concretization, this variant can be treated like any other
-  variant.
+  determines how the package is used rather than how it is installed.
+* During concretization, this variant is treated like any other
+  variant (no changes to the concretization algorithm are required).
 * After concretization, the variant is stripped from the node and
   stored on the edge connecting the node to its parent.
 
@@ -74,6 +74,10 @@ variant('regex', request=True)
 
 This is not essential though: the dependent could universally
 recompute dependency information without any hints from dependents.
+For this reason, the Boost use case can be handled completely
+separately, since any variant modifications would only be used
+to speed up computations and are not required to achieve the
+semantics desired for the use case.
 
 ### Intel Parallel Studio
 
@@ -100,3 +104,11 @@ declaration:
 ```
 variant('threading', interface=True, provider='mkl')
 ```
+
+In other words, this has the same concretization semantics discussed
+for the Intel oneAPI MKL use case (i.e. that this is treated
+exactly the same as other variants during concretization), but
+adds controls on when the variant influences the hash of dependents:
+it only affects the dependent's hash when the dependent is actually
+using the package for the virtual named in the variant's `provider=`
+option.
