의존 지옥

Dependency hell

의존성 지옥은 다른 소프트웨어 [1]패키지의 특정 버전에 의존하는 소프트웨어 패키지를 설치한 일부 소프트웨어 사용자의 불만을 나타내는 용어입니다.

종속성 문제는 여러 패키지가 동일한 공유 패키지 또는 라이브러리에 종속되어 있지만 서로 다른 버전의 공유 패키지에 종속되어 있을 때 발생합니다.공유 패키지 또는 라이브러리를 단일 버전에만 설치할 수 있는 경우 사용자는 종속 패키지의 최신 버전 또는 이전 버전을 가져와 문제를 해결해야 할 수 있습니다.이것에 의해, 다른 의존 관계가 깨져, 문제가 다른 패키지 세트에 푸시 되는 일이 있습니다.

문제

의존성 지옥은 다음과 같은 몇 가지 형태를 취합니다.

많은 의존 관계
애플리케이션은 많은 라이브러리에 의존하며 긴 다운로드, 대량의 디스크 용량 및 매우 휴대성이 필요합니다(모든 라이브러리는 이미 포팅되어 있기 때문에 애플리케이션 자체를 쉽게 포팅할 수 있습니다).또한 모든 종속성을 찾는 것도 어려울 수 있습니다. 이러한 종속성은 저장소가 있으면 해결할 수 있습니다(아래 참조).이는 부분적으로 불가피합니다. 특정 컴퓨팅 플랫폼(Java 등)에 구축된 애플리케이션에서는 해당 플랫폼을 설치해야 하지만 이후 애플리케이션에서는 필요하지 않습니다.이것은 큰 라이브러리의 작은 부분(코드 리팩토링으로 해결할 수 있음)을 사용하는 응용 프로그램이나 단순한 응용 프로그램이 많은 [2]라이브러리에 의존하는 경우 특히 문제가 됩니다.
긴 의존 관계 체인
한다면app에 의존하다liba에 따라 다릅니다.libb, ...에 따라 다릅니다.libz의존관계를 수동으로 해결해야 하는 경우(예를 들어 설치 시도 시) 이는 '많은 의존관계'와는 다릅니다.app를 인스톨 하도록 요구됩니다.liba첫 번째 설치 시도 시liba를 인스톨 하도록 유저에게 요구됩니다.libb등).단, 이 긴 의존관계 체인 중에 같은 패키지의 다른2개의 버전이 필요한[3] 경우 경합이 발생할 수 있습니다(아래의 경합하는 의존관계 참조).이러한 긴 종속성 체인은 모든 종속성을 자동으로 해결하는 패키지 관리자를 통해 해결할 수 있습니다.수동 해결은 모든 종속성을 수동으로 해결하는 번거로움 외에도 종속성 주기 또는 충돌을 가릴 수 있습니다.
모순되는 의존 관계
하나의 소프트웨어에 대한 의존성을 해결하면 다른 소프트웨어의 호환성이 두들겨 패는 것과 유사한 방식으로 깨질 수 있습니다.한다면app1에 의존하다libfoo 1.2,그리고.app2에 의존하다libfoo 1.3, 및 다른 버전의libfoo동시에 설치할 수 없습니다.app1그리고.app2는 동시에 사용할 수 없습니다(또는 설치 관리자가 종속성을 확인하는 경우 설치).가능한 경우 다른 종속성을 동시에 설치할 수 있도록 함으로써 이 문제를 해결할 수 있습니다.또는 새로운 의존관계를 설치하려면 기존 의존관계와 의존관계에 있는 모든 소프트웨어를 제거해야 합니다.다른 디스트리뷰터로부터 패키지를 인스톨 하는 Linux 시스템의 문제(권장되지 않거나 [citation needed]동작하지 않는 것)는, 결과적으로 긴 체인의 의존관계로 인해, 수천개의 패키지가 의존하고 있는 C 표준 라이브러리(GNU C 라이브러리 등)의 버전이 경합하는 경우가 있습니다.이 경우 모든 패키지를 제거하라는 메시지가 표시됩니다.
순환 의존 관계
한다면application A에 따라 다르며 특정 버전이 없으면 실행할 수 없습니다.application B,그렇지만application B에 의존하며, 특정 버전 없이는 실행할 수 없습니다.application A를 업그레이드하면 다른 응용 프로그램이 중단됩니다.이 스킴은 브랜치업에서 더욱 깊어질 수 있습니다.코어 시스템이나 업데이트 소프트웨어 자체에 영향을 미치는 경우, 이 라이브러리(B)를 다음 버전으로 업그레이드할 때 특정 런타임 라이브러리(B)가 작동해야 하는 패키지 관리자(A)가 프로세스 중간에 자체(A)를 브릭할 수 있습니다.라이브러리(B) 버전이 잘못되어 패키지 매니저(A)가 파손되었습니다.따라서 라이브러리(B)의 롤백이나 다운그레이드는 할 수 없습니다.통상적인 솔루션은 두 애플리케이션을 모두 다운로드하여 도입하는 것입니다.경우에 따라서는 일시적인 환경에서도 도입할 수 있습니다.
패키지 관리자 의존 관계
패키지 매니저(APT 등)를 개입시켜 준비된 패키지를 인스톨 하면, 의존 관계가 악화되는 일이 있습니다만[4], 주요 패키지 매니저가 성숙해, 공식 저장소가 잘 유지되고 있기 때문에, 이것은 일어날 가능성이 거의 없습니다.이는 현재 출시된 Debian과 Ubuntu와 같은 주요 파생 모델이 해당됩니다.다만, 패키지 인스톨러(RPM 또는 dpkg 등)를 개입시켜 패키지를 직접 인스톨 하면, 의존성이 저하하는 일이 있습니다.
다이아몬드 의존성
라이브러리 A가 라이브러리 B와 C에 의존하는 경우 B와 C는 모두 라이브러리 D에 의존하지만 B는 버전 D.1이 필요하고 C는 버전 D.2가 필요합니다.최종 실행 파일에는 D 버전이 하나만 존재할 수 있기 때문에 빌드가 실패합니다.
yum과 [5]같은 패키지 매니저는 저장소 패키지 간에 충돌이 발생하기 쉬우며 CentOS 및 Red Hat Enterprise Linux 등의 Linux 배포에서 의존성이 저하됩니다.

솔루션

버전 번호부여
이 문제에 대한 매우 일반적인 해결책은 표준화된 번호 시스템을 사용하는 것입니다.이 시스템에서는 소프트웨어가 각 버전(메이저 버전)에 대해 특정 번호를 사용하고 각 리비전(마이너 버전)에 대해서도 서브 번호(예를 들어 10.1 또는 5.7)를 사용합니다.메이저 버전은 해당 버전을 사용한 프로그램이 더 이상 호환되지 않을 때만 변경됩니다.마이너 버전은 다른 소프트웨어에서 동작하는 것을 방해하지 않는 간단한 리비전이라도 변경할 수 있습니다.이러한 경우 소프트웨어 패키지는 특정 메이저버전을 가진 컴포넌트 및 마이너버전(특정 마이너버전 이상)을 요구할 수 있습니다.따라서 이러한 기능은 계속 작동하며 마이너 버전이 변경되더라도 종속성은 성공적으로 해결됩니다.시멘틱 버전 관리(일명 'SemVer')[6]는 소프트웨어 버전 관리 체계를 작성하기 위해 특별히 포맷된 번호를 사용하는 기술 사양을 생성하는 노력의 한 예입니다.
애플리케이션별 개인 버전
Windows 2000 에 도입된 Windows 파일 보호 기능에 의해서, 애플리케이션이 시스템 DLL 를 덮어쓰지 않게 되었습니다.개발자들은 대신 애플리케이션 디렉토리에 있는 애플리케이션별 라이브러리 복사본인 "프라이빗 DLL"을 사용하도록 권장받았다.여기에는 시스템 전체 라이브러리가 있는 시스템 디렉토리보다 항상 로컬 경로가 우선되는 윈도우즈 검색 경로 특성이 사용됩니다.이것에 의해, 특정의 애플리케이션 마다 라이브러리 버전을 쉽고 효과적으로 쉐도우 할 수 있기 때문에,[7] 의존의 지옥을 회피할 수 있습니다.
PC-BSD(버전 8.2까지 포함) TrueOS(FreeB 기반의 운영체제)의 전신SD)는 /Programs의 자체 포함 디렉토리에 패키지와 의존관계를 배치하여 시스템 라이브러리가 업그레이드 또는 변경되었을 때 파손되는 것을 방지합니다.패키지 관리를 [8]위해 자체 "PBI"(Push Button Installer)를 사용합니다.
여러 버전의 병렬 설치
버전 넘버링 솔루션은 버전 넘버를 오퍼레이팅시스템이 지원하는 기능으로 높임으로써 개선할 수 있습니다.이를 통해 응용 프로그램은 고유한 이름 및 버전 번호 제약으로 모듈/라이브러리를 요청할 수 있으며, 응용 프로그램에서 운영 체제로 라이브러리/모듈 버전을 브로커링하는 책임을 효과적으로 이전할 수 있습니다.그 후 공유 모듈을 중앙 저장소에 배치할 수 있습니다.이러한 모듈은 이전 버전 또는 이후 버전의 모듈에 의존하는 응용 프로그램이 파손될 위험이 없습니다.각 버전은 동일한 모듈의 다른 버전과 나란히 자체 엔트리를 가져옵니다.
이 솔루션은 Windows Vista 이후의 Microsoft Windows 운영체제에서 사용되고 있습니다.Global Assembly Cache는 이러한 중앙 레지스트리와 관련된 서비스를 구현하고 설치 시스템/패키지 매니저와 통합됩니다.Gentoo Linux는 여러 버전의 공유 라이브러리를 [9]설치할 수 있는 슬롯링이라는 개념을 통해 이 문제를 해결합니다.
스마트 패키지 관리
일부 패키지 매니저는 상호의존 소프트웨어 컴포넌트가 동시에 업그레이드되는 스마트업그레이드를 실행할 수 있기 때문에 비호환성의 주요 문제도 해결할 수 있습니다.
현재의 많은 Linux 디스트리뷰션에서는 의존성 문제를 해결하기 위해 저장소 기반 패키지 관리 시스템도 구현되어 있습니다.이러한 시스템은 RPM, dpkg 또는 기타 패키징 시스템 위에 있는 레이어이며 사전 정의된 소프트웨어 저장소를 검색하여 종속성을 자동으로 해결하도록 설계되었습니다.이러한 시스템의 예로는 Apt, Yum, Urpmi, ZYpp, Portage, Pacman 등이 있습니다.일반적으로 소프트웨어 저장소는 FTP 사이트 또는 웹 사이트, 로컬 컴퓨터의 디렉토리 또는 네트워크를 통해 공유되는 디렉토리, 또는 CD나 DVD 등의 이동식 미디어의 디렉토리입니다.이것에 의해, 통상, Linux 디스트리뷰션 프로바이더에 의해서 유지 보수되어 전 세계에 미러링 되고 있는, 이러한 저장소에 패키지 된 소프트웨어의 의존성이 없어집니다.이러한 저장소는 큰 경우가 많지만, 모든 소프트웨어를 포함하는 것은 불가능하기 때문에 의존의 지옥이 발생할 수 있습니다.어느 경우든 저장소 [4]유지보수는 여전히 의존성 문제를 안고 있습니다.
설치 옵션
소프트웨어 조각마다 의존관계가 다르기 때문에 새로운 패키지가 몇 개씩 더 설치되어야 하므로 의존관계 요건의 악순환 또는 계속 확장되는 요건의 트리에 빠질 수 있습니다.Debian Advanced Packaging Tool 등의 시스템에서는 다양한 솔루션을 사용자에게 제시하고 사용자가 필요에 따라 솔루션을 승인 또는 거부할 수 있도록 함으로써 이 문제를 해결할 수 있습니다.
프로그래밍에 대한 간단한 적응성
애플리케이션 소프트웨어가 OS, 윈도 매니저 또는 데스크톱 환경을 다루는 인터페이스 레이어를 새로운 표준 또는 변화하는 표준에 쉽게 적응할 수 있도록 설계되어 있는 경우 프로그래머는 환경 크리에이터 또는 컴포넌트 라이브러리 설계자의 통지를 감시하고 신속하게 조정하기만 하면 됩니다.최소한의 노력으로 시간과 비용이 드는 재설계를 하지 않고 사용자를 위한 업데이트를 제공하는 소프트웨어입니다.이 방법을 사용하면 프로그래머가 관련된 사람에게 부담이 되지 않는 합리적인 통지 프로세스를 유지하도록 압력을 가할 수 있습니다.
코드 개발 및 유지보수의 엄격한 호환성 요건
애플리케이션이나 라이브러리의 개발 및 유지보수가 하위 호환성을 염두에 두고 이루어지면 애플리케이션이나 라이브러리는 언제든지 새로운 버전으로 교체할 수 있습니다.이로 인해 의존성이 많이 완화되지는 않지만 패키지 관리자 또는 설치 관리자의 작업이 훨씬 쉬워집니다.
소프트웨어 어플라이언스
의존관계 문제를 피하기 위한 또 다른 접근법은 애플리케이션을 소프트웨어 어플라이언스로 도입하는 것입니다.소프트웨어 어플라이언스는 사용자가 소프트웨어 의존관계 해결에 대해 더 이상 걱정할 필요가 없도록 미리 통합된 독립형 유닛에 의존관계를 캡슐화합니다.대신 소프트웨어 어플라이언스 개발자에게 부담이 전가됩니다.
휴대용 응용 프로그램
완전히 자급자족하여 이미 설치할 필요가 없는 애플리케이션(또는 기존 기존 애플리케이션의 버전)입니다.필요한 컴포넌트를 모두 포함하도록 코드화되어 있거나 필요한 모든 파일을 자신의 디렉토리에 보관하도록 설계되어 있어 의존성 문제가 발생하지 않습니다.접속되어 있는 시스템과는 독립적으로 실행할 수 있는 경우가 많습니다.RISC OS 및 ROX Desktop for Linux 의 애플리케이션은, 애플리케이션 디렉토리를 사용합니다.이 디렉토리는 거의 같은 방법으로 동작합니다.프로그램과 그 의존관계는 독자적인 디렉토리(폴더)[10]에 포함되어 있습니다.
이 배포 방법은 Unix와 유사한 플랫폼용으로 설계된 애플리케이션을 Windows로 이식할 때도 유용하다는 것이 입증되었습니다.가장 눈에 띄는 단점은 동일한 공유 라이브러리를 여러 개 설치하는 것입니다.예를 들어 gedit, GIMP 및 HexChat용 Windows 설치 프로그램에는 모두 위젯 렌더링에 사용되는 GTK 툴킷의 동일한 복사본이 포함되어 있습니다.한편, 애플리케이션 마다 다른 버전의 GTK 가 필요한 경우는, 이것이 올바른 동작이며, 의존의 지옥을 회피할 수 있습니다.

플랫폼 고유의

특정 컴퓨팅 플랫폼에서 "의존 지옥"은 종종 로컬 고유의 이름(일반적으로 컴포넌트 이름)으로 통합니다.

  • DLL Hell – Microsoft Windows에서 발생하는 의존 지옥의 일종입니다.
  • 확장 충돌 – 기존 Mac OS에서 발생하는 의존 지옥의 한 형태입니다.
  • JAR hell – 2004년에 [citation needed]Apache Maven과 같은 빌드 툴이 이 문제를 해결하기 전에 Java Runtime Environment에서 발생한 일종의 의존 지옥입니다.
  • RPM 지옥– Linux의 Red Hat 디스트리뷰션 및 RPM을 패키지 [11]매니저로 사용하는 기타 디스트리뷰션에서 발생하는 의존성 지옥의 일종입니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ Michael Jang (2006). Linux annoyances for geeks. O'Reilly Media. p. 325. ISBN 9780596552244. Retrieved 2012-02-16.
  2. ^ Donald, James (2003-01-25). "Improved Portability of Shared Libraries" (PDF). Princeton University. Archived from the original (PDF) on 2007-09-26. Retrieved 2010-04-09. {{cite journal}}:Cite 저널 요구 사항 journal=(도움말)
  3. ^ a b Pjotr Prins; Jeeva Suresh & Eelco Dolstra (2008-12-22). "Nix fixes dependency hell on all Linux distributions". linux.com. Archived from the original on 2015-07-08. Retrieved 2013-05-22. All popular package managers, including APT, RPM and the FreeBSD Ports Collection, suffer from the problem of destructive upgrades. When you perform an upgrade -- whether for a single application or your entire operating system -- the package manager will overwrite the files that are currently on your system with newer versions. As long as packages are always perfectly backward-compatible, this is not a problem, but in the real world, packages are anything but perfectly backward-compatible. Suppose you upgrade Firefox, and your package manager decides that you need a newer version of GTK as well. If the new GTK is not quite backward-compatible, then other applications on your system might suddenly break. In the Windows world a similar problem is known as the DLL hell, but dependency hell is just as much a problem in the Unix world, if not a bigger one, because Unix programs tend to have many external dependencies.
  4. ^ "Yum Dependency Hell". Archived from the original on 2016-12-19. Retrieved 2015-12-28.
  5. ^ "Project website: semver.org".
  6. ^ Anderson, Rick (2000-01-11). "The End of DLL Hell". microsoft.com. Archived from the original on 2001-06-05. Retrieved 2010-07-07.
  7. ^ pbiDIR
  8. ^ gentoo.org에서의 스케줄 설정
  9. ^ "Application directories". Retrieved 7 September 2013.
  10. ^ Weinstein, Paul (2003-09-11). "Is Linux Annoying?". linuxdevcenter.com. Retrieved 2010-04-10.

외부 링크