package preference vs package masking

[trws]

PR #261 adds support for a "preferred version" as a stopgap waiting for #120 and more generic preference mechanisms. Neither of these seems to offer a mechanism for specifying versions that are available but unstable, and thus which shouldn't be used without explicit request. The ability to use a masking flag, variant, or just something logically opposite to "preferred" might be a clean way to deal with adding things like "HEAD" versions for some packages without having to track a specific "preferred" version below that to keep it out of the list. Using something like gentoo's mask names might make it a bit more flexible still, where packages can be stable, unstable, test, etc. and enabled only by specifying the levels to be unmasked. That may be excessive here, but the basic concept would help.

[tgamblin]

We don't have this in there right now but it's very easy to add with the current concretization mechanism. All the action happens in concretize_version, where a list of versions is currently compiled and ordered according to preference. You could make that a little more sophisticated and add tiers of stability, and then all we'd need is a config file option to customize it...

[alalazo]

@trws Spending some time on old issues. Right now we have both "preferred" versions (which are selected before others) and deprecated versions (which are avoided at concretization time as much as possible and are not shown by spack info). Would that be enough to close this?

[trws]

Wow this is an old one... I think we can close this, both because there are deprecated versions to handle poorly supported or old versions and because string versions sort as older than number versions now so they don't get auto-selected like they did at the time. Good triage! Closing.