Removed documentation on false paths as per #2083 (#2146)

Removed documentation on false paths as per #2083
This commit is contained in:
Elizabeth Fischer 2016-10-26 20:11:54 -04:00 committed by Todd Gamblin
parent 9f54cea5c5
commit 3895c974a0
2 changed files with 1 additions and 40 deletions

View file

@ -134,34 +134,6 @@ buggy or otherwise undesirable.
.. _system-packages:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
False Paths for System Packages
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Sometimes, the externally-installed package one wishes to use with
Spack comes with the Operating System and is installed in a standard
place --- ``/usr``, for example. Many other packages are there as
well. If Spack adds it to build paths, then some packages might
pick up dependencies from ``/usr`` than the intended Spack version.
In order to avoid this problem, it is advisable to specify a fake path
in ``packages.yaml``, thereby preventing Spack from adding the real
path to compiler command lines. This will work because compilers
normally search standard system paths, even if they are not on the
command line. For example:
.. code-block:: yaml
packages:
# Recommended for security reasons
# Do not install OpenSSL as non-root user.
openssl:
paths:
openssl@system: /false/path
version: [system]
buildable: False
^^^^^^^^^^^^^^^^^^^^^^^^^^
Extracting System Packages
^^^^^^^^^^^^^^^^^^^^^^^^^^

View file

@ -730,21 +730,10 @@ there." This is reasonable for OpenSSL, which has a stable API.
packages:
openssl:
paths:
openssl@system: /false/path
openssl@system: /usr
version: [system]
buildable: False
.. note::
Even though OpenSSL is located in ``/usr``, We have told Spack to
look for it in ``/false/path``. This prevents ``/usr`` from being
added to compilation paths and RPATHs, where it could cause
unrelated system libraries to be used instead of their Spack
equivalents.
The adding of ``/usr`` to ``RPATH`` in this sitution is a known issue
and will be fixed in a future release.
^^^^^^^^^^^^^
BLAS / LAPACK