Debian
libc6和libgcc1的相互依賴
我發現這兩個包相互依賴（在 中）
libgcc1，所以沒有另一個就不能存在。 這是為什麼？一個包不應該依賴於另一個包而不是最終依賴於它自己……？libc6``debian 10$ LC_ALL=C apt depends libgcc1 libc6 libgcc1 Depends: gcc-8-base (= 8.3.0-6) Depends: libc6 (>= 2.14) Breaks: <gcc-4.3> (<< 4.3.6-1) Breaks: <gcc-4.4> (<< 4.4.6-4) Breaks: <gcc-4.5> (<< 4.5.3-2) libc6 Depends: libgcc1 Conflicts: openrc (<< 0.27-2~) Breaks: <hurd> (<< 1:0.5.git20140203-1) Breaks: <libtirpc1> (<< 0.2.3) Breaks: locales (<< 2.28) Breaks: locales-all (<< 2.28) Breaks: nocache (<< 1.1-1~) Breaks: nscd (<< 2.28) Breaks: r-cran-later (<< 0.7.5+dfsg-2) Recommends: libidn2-0 (>= 2.0.5~) Suggests: glibc-doc |Suggests: debconf Suggests: <debconf-2.0> cdebconf debconf Suggests: libc-l10n Suggests: locales
從包管理器的角度來看，有幾種依賴關係。
首先是BUILD依賴項：解壓、修補、編譯、測試或安裝包所需的任何包。
如果 Pack-D 是 Pack-foo 的建構依賴項，則在 Pack-foo 建構時需要 Pack-D 的操作發生。（vg 不在 Pack-foo 執行時）。
有了這種依賴，（通常）就不用擔心你想到的可怕的*循環依賴了。*Pack-D 在建構時可能毫無困難地需要 Pack-foo。例如，將 gcc 視為某些 zipper 的建構依賴項，而 zipper 本身是 gcc 的建構依賴項，因為您的包管理器依賴於 gcc 的某些壓縮分發。
秒是RUN TIME依賴項。包執行所需的任何包。語言解釋器，當然是數據文件，但更普遍的是：連結階段正確進行所需的庫。
在這些特殊情況下，您正確地認為如果 lib-A 是 lib-B 的執行時依賴項，那麼 lib-B 不應該反過來成為 lib-A 的執行時依賴項，因為這會產生要避免的循環依賴項任何狀況之下。
ldd 或 lddtree 是了解這些依賴關係的好工具。在我的系統上，lddtree 會告訴 libc6 實際上是 libgcc1 的執行時依賴項
# lddtree /usr/lib/gcc/x86_64-pc-linux-gnu/9.4.0/libgcc_s.so.1 libgcc_s.so.1 (interpreter => None) libc.so.6 => /lib64/libc.so.6 ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2但是 libgcc1 不是 libc6 的執行時依賴項：
# lddtree /usr/lib/gcc/x86_64-pc-linux-gnu/9.4.0/lib64/libc.so.6 /lib64/libc.so.6 (interpreter => /lib64/ld-linux-x86-64.so.2) ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2那裡沒有循環依賴，沒有什麼可擔心的。
三分之二是BLOCKERS：一些包管理器（例如gentoo portage）欺騙依賴聲明來指定應該或不應該在系統中共存的包。當然，這些並不構成循環依賴。