Skip to content

Patching: do strict version range checking#13989

Merged
tgamblin merged 3 commits intospack:developfrom
scheibelp:bugfix/patch-checks-version-ranges
Dec 5, 2019
Merged

Patching: do strict version range checking#13989
tgamblin merged 3 commits intospack:developfrom
scheibelp:bugfix/patch-checks-version-ranges

Conversation

@scheibelp
Copy link
Copy Markdown
Member

@scheibelp scheibelp commented Dec 5, 2019

Fixes #13961

Apply strict constraint checks for patches, otherwise Spack may incorrectly treat a version range constraint as satisfied when mixing x.y and x.y.z versions.

See also: #8957 (comment)

@mwkrentel
Copy link
Copy Markdown
Member

I tested this and I agree this fixes the problem I reported in #13961.

I also agree this is only a problem for patch. At least, I couldn't
produce a counter-example for conflicts or depends_on.


So, this fixes the case of how to interpret a short name in a spec, as
in spack install intel-tbb @2019. But there remains the case of how
to write a short name inside when.

Intel-tbb has versions 2019, 2019.1, 2019.2, etc. How do I write
patch, or conflicts or depends_on with when that applies to exactly
version 2019 and not 2019.1?

I can't use when='@2019' because that is interpreted broadly, as in
@2019:2019.99.

In this case, there is a workaround: when='@2019:2019.0'. This
works because there is no version 2019.0. But what if there was?
How can I include 2019 but not 2019.0?

Basically, I don't see a way to tell when that a short name is
supposed to mean exactly that one rev, nothing more.
It's too bad that @2019:2019 doesn't work.

But that's really a problem for #8957. Don't let it delay committing
this patch.

Thanks!

@tgamblin tgamblin merged commit e9ee9ea into spack:develop Dec 5, 2019
mwkrentel added a commit to mwkrentel/spack that referenced this pull request Dec 9, 2019
Recent commit e9ee9ea (spack#13989) fixed testing version ranges inside
patch when clauses.  Previously, it was necessary to write all revs
individually for packages with multiple length version numbers (2019
and 2019.1).

This fixes the build for the old 2017.* versions.
adamjstewart pushed a commit that referenced this pull request Dec 9, 2019
Recent commit e9ee9ea (#13989) fixed testing version ranges inside
patch when clauses.  Previously, it was necessary to write all revs
individually for packages with multiple length version numbers (2019
and 2019.1).

This fixes the build for the old 2017.* versions.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

variable length version numbers don't obey a linear order

3 participants