Conda 在控制包的必要依赖项方面做得很好，但显然大多数包都将 C 库排除为可跟踪依赖项。例如，让我们使用以下命令安装 Gnuastro：
conda install -c conda-forge gnuastro
然后，我查看了 Gnuastro 的一个程序链接的库（例如astnoisechisel）：
$ ldd $(which astnoisechisel)
linux-vdso.so.1 (0x00007ffdbd336000)
libgnuastro.so.9 => /path/to/conda/install/envs/testenv/bin/../lib/libgnuastro.so.9 (0x00007fe039ce1000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe039b86000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe0399c6000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe0399a5000)
libgit2.so.28 => /path/to/conda/install/envs/testenv/bin/../lib/./libgit2.so.28 (0x00007fe039882000)
libtiff.so.5 => /path/to/conda/install/envs/testenv/bin/../lib/./libtiff.so.5 (0x00007fe039800000)
liblzma.so.5 => /path/to/conda/install/envs/testenv/bin/../lib/./liblzma.so.5 (0x00007fe0397d7000)
libjpeg.so.9 => /path/to/conda/install/envs/testenv/bin/../lib/./libjpeg.so.9 (0x00007fe039799000)
libwcs.so.5 => /path/to/conda/install/envs/testenv/bin/../lib/./libwcs.so.5 (0x00007fe03963e000)
libcfitsio.so.8 => /path/to/conda/install/envs/testenv/bin/../lib/./libcfitsio.so.8 (0x00007fe039311000)
libcurl.so.4 => /path/to/conda/install/envs/testenv/bin/../lib/./libcurl.so.4 (0x00007fe03928b000)
libz.so.1 => /path/to/conda/install/envs/testenv/bin/../lib/./libz.so.1 (0x00007fe03926f000)
libgsl.so.23 => /path/to/conda/install/envs/testenv/bin/../lib/./libgsl.so.23 (0x00007fe038fc6000)
libcblas.so.3 => /path/to/conda/install/envs/testenv/bin/../lib/./libcblas.so.3 (0x00007fe03740d000)
/lib64/ld-linux-x86-64.so.2 (0x00007fe03a049000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007fe037402000)
libssl.so.1.1 => /path/to/conda/install/envs/testenv/bin/../lib/././libssl.so.1.1 (0x00007fe037372000)
libcrypto.so.1.1 => /path/to/conda/install/envs/testenv/bin/../lib/././libcrypto.so.1.1 (0x00007fe0370c4000)
libssh2.so.1 => /path/to/conda/install/envs/testenv/bin/../lib/././libssh2.so.1 (0x00007fe03708f000)
libzstd.so.1 => /path/to/conda/install/envs/testenv/bin/../lib/././libzstd.so.1 (0x00007fe036fd3000)
libbz2.so.1.0 => /path/to/conda/install/envs/testenv/bin/../lib/././libbz2.so.1.0 (0x00007fe036fbf000)
libgssapi_krb5.so.2 => /path/to/conda/install/envs/testenv/bin/../lib/././libgssapi_krb5.so.2 (0x00007fe036f70000)
libkrb5.so.3 => /path/to/conda/install/envs/testenv/bin/../lib/././libkrb5.so.3 (0x00007fe036e99000)
libk5crypto.so.3 => /path/to/conda/install/envs/testenv/bin/../lib/././libk5crypto.so.3 (0x00007fe036e78000)
libcom_err.so.3 => /path/to/conda/install/envs/testenv/bin/../lib/././libcom_err.so.3 (0x00007fe036e72000)
libgfortran.so.4 => /path/to/conda/install/envs/testenv/bin/../lib/././libgfortran.so.4 (0x00007fe036d44000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe036d3f000)
libkrb5support.so.0 => /path/to/conda/install/envs/testenv/bin/../lib/./././libkrb5support.so.0 (0x00007fe036d31000)
libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007fe036d17000)
libquadmath.so.0 => /path/to/conda/install/envs/testenv/bin/../lib/././libquadmath.so.0 (0x00007fe036cdd000)
libgcc_s.so.1 => /path/to/conda/install/envs/testenv/bin/../lib/././libgcc_s.so.1 (0x00007fe036cc9000)
所有使用的高级库都在 Conda 环境中，除了 C 库：libm.so.6、libc.so.6、libpthread.so.0、librt.so.1、libdl.so.2和libresolv.so.2ofcourse ld-linux-x86-64.so.2。
我在 Conda-forge 上找不到 GNU C 库，但是当我进行搜索时，我发现了其他一些拥有它的项目。所以例如我试过：
conda install -c neok.m4700 glibc
这安装了 GNU C 库 2.30（3 个月前创建的 Conda tarball），ldd上面的命令给了我一个漂亮的列表，其中包含了 Conda 安装中的所有内容。在一个测试 Conda 环境中，调用给astnoisechisel --version了一个分段错误，而在另一个环境中它成功了。然后我尝试了另一个 Conda C 库（在干净的环境中）：
conda install -c asmeurer glibc
这是旧版本的 C 库（最近一次更新是 5 年前：glibc 2.19）。在这种环境下，我的astnoisechisel --version命令只会给出分段错误和崩溃。
在这个 conda-forge 讨论中，据说“ glibc 是不好发布的东西，如果我们不能使用系统 glibc，我很担心这个包。它与内核版本紧密相关，并且使用旧版本也是一种安全风险”。所以我想包含 GNU C 库（至少在 GNU/Linux 系统上）不是他们的政策。
我还看到 Anaconda 中的“基本”包存在类似问题。例如，当我检查 or 的链接标志curl时zstd。
所以我的问题是：如果 C 库没有被正式定义为依赖项（就像所有其他依赖项一样），那么在不久的将来（比如 5 年），Conda 包（尤其是旧版本的软件）的可靠性如何在上述情况下）？
类似的说明：假设我需要手动获取用于构建 Conda 包的正确 C 库（以便能够运行可执行文件）。用于构建该软件包的 C 库版本是否记录在下载的 tarball 中的任何位置？