Open vanderwb opened 5 months ago
Yeah, I don't like the current implementation either.
x%gcc@x.y.z
should imply a direct dependency on gcc-runtime@x.y.z
.
Currently if you first install zlib %gcc@old
and then concetrize parent %gcc@new
, it will reuse zlib ^gcc-runtime@old
as is. But if there is no zlib
to reuse, you get zlib ^gcc-runtime@new
, which leads to more duplication than necessary.
Summary
Before the
gcc-runtime
package was introduced back in December, it was possible to use older GCC versions (e.g., the system GCC) to compile low-level package dependencies and then userequire:
settings to force the concretizer to reuse those versions, even whenreuse: false
. With the introduction of the runtime packages, this seems impossible now.For example, let's say I have the following restriction set:
In older versions, a spec like
hdf5~mpi%gcc@13.2.0
would then use the already-installed zlib. But now, because gcc-runtime always seems to use the parent runtime version, a duplicate zlib installation is created:However, the concretizer will use the correct zlib if explicitly forced (this causes the concretizer to use a different curl version for some reason, but that's not an immediate concern):
I haven't been able to find a way to produce this reuse behavior without explicitly specifying hashes of dependencies, which isn't tenable for a whole stack. If I try to require
%gcc@7.5.0 ^gcc-runtime@7.5.0
on zlib, I get this error upon concretization:Rationale
This used to work, and since older runtimes should be compatible with newer compilers, I think the request here is valid from a linking standpoint. Without the desired behavior, the ability to reuse packages compiled with older runtimes is restricted.
Description
I'd like to be able to request that low-level packages like zlib, curl, cmake, etc... be compiled only once within a
reuse: false
stack. We like to build subsets of our larger stack for container images and other use cases, and withreuse: true
, the subset will not concretize to the same packages as the main stack and so the binary cache we have becomes much less useful.In summary, I'm creating this issue to:
a) State the concern b) Understand whether the current behavior is desired (and thus will persist into the "compilers as dependencies" era) c) Find out an estimated timeline for a fix, if the current behavior is not the final goal
We haven't been able to use any versions of Spack since December when the
gcc-runtime
package was introduced, and this is becoming more challenging to deal with as our HPC users request new package versions.Additional information
Most recently tested with:
General information