Egbert Eich
93b53787f6
fix infinite recursion when computing concretization
errors
+ environment: fix an issue with
deconcretization/reconcretization of specs
+ buildcache: don't error if a patch is missing, when
installing from binaries
In v0.18, we added better error messages that could tell you
what problem happened, but they couldn't tell you why it
happened. 0.21 adds condition chaining to the solver, and
Spack can now trace back through the conditions that led to
an error and build a tree of causes potential causes and
where they came from.
This creates a container image from the Spack installations
on the host system, without the need to run spack install
from a Dockerfile or sif file. It also addresses the
inconvenience of losing binaries of dependencies when RUN
spack install fails inside docker build. Further, the
container image layers and build cache tarballs are the same
files. This means that spack install and docker pull use the
exact same underlying binaries. If you previously used spack
install inside of docker build, this feature helps you save
storage by a factor two.
Increasingly, complex package builds require multiple
versions of some build dependencies. For example, Python
packages frequently require very specific versions of
setuptools, cython, and sometimes different physics packages
require different versions of Python to build. The
concretizer enforced that every solve was unified, i.e.,
that there only be one version of every package. The
concretizer now supports "duplicate" nodes for build
OBS-URL: https://build.opensuse.org/request/show/1143459
OBS-URL: https://build.opensuse.org/package/show/network:cluster/spack?expand=0&rev=91
|
||
|---|---|---|
| _constraints | ||
| _multibuild | ||
| .gitattributes | ||
| .gitignore | ||
| Adapt-shell-scripts-that-set-up-the-environment-for-different-shells.patch | ||
| Add-support-for-container-building-using-a-SLE-base-container.patch | ||
| added-target-and-os-calls-to-output-of-spack-spec-co.patch | ||
| Fix-error-during-documentation-build-due-to-recursive-module-inclusion.patch | ||
| Fix-Spinx-configuration-to-avoid-throwing-errors.patch | ||
| Make-spack-paths-compliant-to-distro-installation.patch | ||
| objects.inv | ||
| README-oo-wiki | ||
| README.SUSE | ||
| run-find-external.sh.in | ||
| Set-modules-default-to-lmod.patch | ||
| spack_get_libs.sh | ||
| spack-0.21.1.tar.gz | ||
| spack-rpmlintrc | ||
| spack.changes | ||
| spack.spec | ||
openSUSE/SUSE specific Settings ============================================= The packages build by a regular user are stored in the home directory and so only available for this user. When the packages should be available for all users on a system, the user who builds the packages, must be able to write to the global spack user directories under /usr/lib/spack/ Packages stored under this path are available for all user via lmod. To add a user to the group spack so that he can write to the global spack directory, execute (as root): # usermod -a -G spack <user_login> and change the setting for 'install_tree:' to the global spack directory in the configuration '~/.spack/config.yaml' for this user. NOTE: As the recipes are contributed by the spack community and rely also on external packages, a signification part of the recipes may fail to create packages.