We've received some requests for an upgrade-in-place capability in Spack.

My current thoughts on the policy side:

• We want to maintain the unique mapping from specs to prefixes
• We want to be able to deprecate software with security flaws without breaking packages that depend on it.

On the technical side, to accomplish the above:

• We cannot install a new spec over the existing install
• We can remove the old installation and create a symbolic link from the old installation to a new one.
• We can note in the install database that the old installation was deprecated and symlink'ed into the new installation.
• Once the new compiler is implemented, we can prevent the concretizer from concretizing against the old spec.

Proposal:

I will create a spack upgrade or spack deprecate command that takes two specs, the spec to deprecate and the spec to replace it with. It will implement the removal of the old binaries and the creation of the symlink from the old prefix to the new. This will also make the database changes necessary, but will not implement the changes to the concretizer as the current concretizer implementation cannot handle that logic.

Comments on either policy or technical specs are welcome. I will leave this up at least a few days before beginning implementation to give people an opportunity to comment.