{endcode}
However, there are a couple of problems with that. The first problem is defaulting. When a has requirements that don't mention OpSysMajor, the submit side needs to add in a clause picking one. This is what condor_submit does today with OpSys and Arch. This is hard-coded into the condor_submit executable, and is difficult to replicate in configuration, *but it is possible*, though ugly. We can simulate this today in config which looks for the string OpSysMajor in requirements, and if it is there, we can assume that the job is correctly selecting a version. One can construct all kinds of expressions for which this isn't true, but it should work in practice, as it does for OpSys and Arch.
+
+Using existing submit requirements, this can be done with
+{code}
+JOB_TRANSFORM_NAMES = EL, EL_VER
+JOB_TRANSFORM_EL @= end
+[
+ Requirements = Regexp("OpSysMajorVer",UnParse(Requirements),"i") =?= false;
+ copy_Requirements = "OrigRequirements";
+ set_Requirements = (Target.OpSysMajorVer == 6) && OrigRequirements;
+ set_AmTransformed = true;
+]
+@end
+
+JOB_TRANSFORM_EL_VER @= end
+[
+ eval_set_WantELVer = isError(int(Regexps("OpSysMajorVer == ([0-9])", UnParse(Requirements), "\\\\1", "i"))) ? 0 : int(Regexps("OpSysMajorVer == ([0-9])", UnParse(Requirements), "\\\\1", "i"));
+]
+@end
+{endcode}
+
+Note that relying on a regexp match of an UnParse is suboptimal. We can then add in 8.7.x a classad ContainsAttr function that returns true iff the expression references (directly or indirectly) some named attribute. This would make the code more robust and simpler.
+
+These expressions simplify the Requirements expression, and obey the principle of least surprise for our users -- when they request a OpSysMajorVer, no changes are made to their requirements.
+
+Also note the EL_VER, which can be used by GlideinWMS to extract into a simple attribute which version is being requested. This could also be used in a docker, VM, or singularity environment to create a machine of a given type.
