用于高性能计算的spack软件源

[fangjzh]

镜像名: spack mirror 上游路径: https://mirror.spack.io 镜像简介: Spack is a package management tool designed to support multiple versions and configurations of software on a wide variety of platforms and environments. It was designed for large supercomputing centers, where many users and application teams share common installations of software on clusters with exotic architectures, using libraries that do not have a standard ABI. Spack is non-destructive: installing a new version does not break existing installations, so many configurations can coexist on the same system.

国内其他镜像源同步情况: 没有找到国内源，官方源非常慢且不稳定，急缺。

同步方法:

镜像大小:

状态追踪:

• [ ] 同意同步
• [ ] 同步脚本
• [ ] 部署到镜像源
• [ ] 首次同步成功
• [ ] 测试脚本
• [ ] 使用文档
• [ ] 添加到官方源

[specter119]

我不是维护者。 P.S.: 我在 pi 上用 spack, 然后在我们组自己的小集群上也从头搭过 spack。已毕业，经验基于2年前，下面搜的文档还是新的。

FYI.

• https://spack.readthedocs.io/en/latest/mirrors.html
• https://spack-tutorial.readthedocs.io/en/latest/tutorial_binary_cache.html

我觉得它虽然叫 mirror，其实还是个 cache? 可以尝试先删除了 spack 官方的 mirror，只用本地？理论上它会从每个包比较官方的地方下，或许不会再发生类似“非常慢”的情况？

我只是觉得，对于 spack 这种什么都编译的东西，把它需要的 tar 包再建个 mirror，怪怪的。

[fangjzh]

我不是维护者。 P.S.: 我在 pi 上用 spack, 然后在我们组自己的小集群上也从头搭过 spack。已毕业，经验基于2年前，下面搜的文档还是新的。

FYI.

* https://spack.readthedocs.io/en/latest/mirrors.html

* https://spack-tutorial.readthedocs.io/en/latest/tutorial_binary_cache.html

我觉得它虽然叫 mirror，其实还是个 cache? 可以尝试先删除了 spack 官方的 mirror，只用本地？理论上它会从每个包比较官方的地方下，或许不会再发生类似“非常慢”的情况？

我只是觉得，对于 spack 这种什么都编译的东西，把它需要的 tar 包再建个 mirror，怪怪的。

我也是新手，目前了解大概是官方mirror是一些源码包，然后第三方mirror是编译好的二进制文件，但是要匹配操作系统编译器以及软件的版本及编译参数，才能直接用它的二进制包。我前段时间在Rocky Linux中试用了一下spack，添加了第三方的源 spack mirror add E4S https://cache.e4s.io spack buildcache keys -it 这个站点 https://oaciss.uoregon.edu/e4s/inventory.html 页面上列出了他们编译过的一些软件版本，算是你说的cache。但我实际使用起来还是什么都得编译，可能和操作系统有关系（页面上有明确的操作系统区分，centos 和redhat分开的）。可能这个请求最终没啥意义，我也是初用github，暂时不关闭，留个讨论的地方。

[skyzh]

SJTUG mirror 不会做类似 build farm 的服务，所以最多做个源码镜像。

[fangjzh]

SJTUG mirror 不会做类似 build farm 的服务，所以最多做个源码镜像。

能做源码镜像也挺有意义 ^_^，官方下载中断还是常有的事情.