- deactivate -a errors if arg is not activated
- deactivate -af does not.

- bleeding edge still available but commented by default.

Conflicts:
	var/spack/packages/libpng/package.py

- doesn't build correctly with boost 1.55

spack activate
  - now activates dependency extensions
  - ensures dependencies are activated in the python installation.
  - -f/--force option still allows the old activate behavior.

spack deactivate
  - checks for dependents before deactivating (like uninstall)
  - deactivate -a/--all <extension> will deactviate a package and ALL
    of its dependency extensions.
  - deactivate -a/--all <extendee> activates all extensions of <extendee>
    e.g.: spack deactivate -a python
  - deactivate -f/--force option allows removing regardless of dependents.
    - deactivate -f can be run EVEN if a package is not activated.
    - allows for clenup of activations gone wrong.

spack deactivate -f will unlink even if Spack thinks the package isn't enabled.
Made deactivate routines idempotent.

- Added a number of dependencies to python packages.
- Python packages may still not build without some OS support.
- Example: Numpy needs ATLAS, and will use a system ATLAS install.
  - Atlas requires turning off CPU throttling to build.
  - can't do this as a regular user -- how to build ATLAS with Spack
  - currnetly relying on a system ATLAS install.

- Real bottleneck is calling normalize() for every spec when we read it.
- Need to store graph information in spec files to avoid the need for this.
  - Also, normalizing old specs isn't always possible, so we need to do this anyway.

Conflicts:
	var/spack/packages/qt/package.py

Features/memaxes