私は2つのパッケージが互いに依存しているので、どちらも単独で存在できないことを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
答え1
パッケージマネージャの観点からは、いくつかのタイプがあります。依存関係。
まず立てる依存関係：パッケージの解凍、パッチ、コンパイル、テスト、またはインストールに必要なすべてのパッケージ。
Pack-D が Pack-foo のビルド依存関係である場合は、Pack-foo のビルド時に Pack-D を実行する必要があります。 （Pack-fooが実行されているときはvgは存在しません）。
この依存関係を使用すると（一般的に）心配することが少なくなります。循環依存性考えてみてください。 Pack-Dは、問題なくビルドするときにPack-fooが必要な場合があります。たとえば、gccをジッパーのビルド依存関係として考えてみましょう。ジッパー自体はgccのビルド依存関係です。パッケージマネージャはgccのいくつかのジッパーディストリビューションに依存しているからです。
秒数は次のとおりです。走る依存関係。パッケージの実行に必要なすべてのパッケージです。もちろん、言語ソルバー、データファイル、しかしより一般的には、接続ステップが正しく機能するために必要なライブラリです。
このような特別なケースでは、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
そこには循環依存関係はありません。それでは心配することはありません。。
3分の2ブロッカー：一部のパッケージマネージャ（Gentoo Fortageなど）は、依存関係宣言をだまして、どのパッケージがシステムに共存するか、存在しないかを指定します。もちろん、これは循環依存関係を構成しません。