나는 두 패키지가 서로 의존하므로( 에서) 어느 하나도 단독으로 존재할 수 없다는 것을 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는차단제: 일부 패키지 관리자(예: 젠투 포티지)는 종속성 선언을 속여 어떤 패키지가 시스템에 공존해야 하는지 또는 존재하지 않아야 하는지 지정합니다. 물론 이것은 순환 종속성을 구성하지 않습니다.