Linux 배포판마다 패키지 형식(및 패키지 관리자)이 다른 이유는 무엇입니까?

패키지 관리는 매우 복잡한 문제이며, 이를 해결하기 위한 다양한 시도가 있어 왔습니다. 각 시도는 이전 시도를 개선하려고 시도하지만 완벽한 것은 없습니다.

패키지 관리 시스템과 형식이 함께 설계되었기 때문에 각 패키지 관리 시스템은 자체 형식을 사용합니다. 이론적으로는 모든 시스템이 사용할 수 있는 통일된 형식이 있을 수 있지만 종속성 그래프 생성, 패치 관리, 구성 파일 콘텐츠 및 배치, 심지어 패키지 간의 버전 호환성과 같은 패키지 관리의 다른 측면도 변경되어야 합니다. 패키지를 상호 교환할 수 있도록 통합되었습니다.

모든 패키지 관리 시스템은 종속성 관리에 대해 서로 다른 접근 방식을 취하고 모든 배포판은 패키지 버전 선택 및 패치 관리에 대해 서로 다른 접근 방식을 취하므로 이를 통합할 방법이 없습니다.

이러한 선택으로 Linux 배포판이 구성됩니다. 이를 통합하려는 것은 모든 배포판을 하나로 병합하려는 것입니다. 이것이 패키지 관리 시스템이 배포판의 핵심인 이유입니다. 배포판을 결정하는 결정은 여기서 나옵니다. 사실 이것보다 더 잘 설명할 수 있는 방법은 없어요https://xkcd.com/927/

이식 가능한 패키지 형식을 만들려는 시도가 많이 있었습니다. Appimage는 그 중 하나입니다. 배포 패키지에 (거의) 모든 종속성을 내장하여 작동하므로 패키지가 매우 커지고 불필요한 메모리를 사용합니다.

또 다른 옵션은 스냅입니다. 이는 운영 체제에서 종속성을 다시 분리하고 자체적으로 처리하려고 시도하므로 하나의 스냅 패키지가 종속된 다른 스냅 패키지를 끌어와 운영 체제 구성 요소의 버전을 다시 복제할 수 있습니다.

최종 이식 가능한 기본 패키지는 수동으로 패치, 구성, 컴파일 및 설치해야 하는 소스 코드 파일의 tarball입니다. 여기에는 종속성이 포함되지 않으므로 설치 프로그램은 컴파일하기 전에 종속성을 해결해야 합니다. 종속성을 나열하는 표준 방법이 없기 때문에 상황이 더욱 악화되고 일부 패키지는 libc에 있는 내용까지 시스템에서 표준으로 사용할 수 있는 항목에 대해 많은 가정이 있기 때문에 신경 쓰지도 않습니다.

이 문제를 해결하는 더 좋은 방법은 없습니다. 모든 솔루션에는 문제가 있습니다. 문제를 해결하기 위한 솔루션을 만들면 서로 다른 문제가 발생할 뿐이며 많은 솔루션은 상호 배타적입니다.

간단한 대답은주된 이유Linux 배포판은 다음을 위해 존재하기 때문에분포일관된 패키지 세트. 영원히 동일한 버전에 머물고 싶지 않기 때문에 업그레이드할 방법도 필요합니다. 필요하지 않은 소프트웨어를 설치하고 싶지 않기 때문에 필요한 패키지를 선택하는 방법이 필요합니다. 미래를 예측할 수 없으므로 나중에 패키지를 설치하거나 제거하여 이 선택을 변경할 수 있는 방법이 필요합니다. 재사용은 소프트웨어 엔지니어링의 기본 원칙 중 하나이므로 패키지는 다른 패키지에 종속되므로 이러한 종속성을 처리할 방법이 필요합니다.

이 모든 것이 패키지 관리 시스템의 탄생으로 이어졌습니다.

따라서 누군가가 새로운 Linux 배포판을 만든다면 이는 아마도 기존의 모든 Linux 배포판에 문제가 있다고 생각한다는 의미일 것입니다. 패키지 관리는 Linux 배포판의 기본이기 때문에 그들이 동의하지 않는 것 중 하나가 패키지 관리 시스템일 가능성이 높습니다.

이는 "왜 우리는 여러 개의 패키지 관리 시스템을 가지고 있는가"라는 질문에 실제로 대답하지 않고 "왜 우리는 여러 개의 Linux 배포판을 가지고 있는가"로 되돌아갑니다.

이제 당신은아니요Linux 배포판이 여러 개 있는 이유에 대해 질문해 보세요. 그러나 왜 여러 패키지 관리자가 있는지 의문을 제기해서는 안 됩니다.

그건 그렇고, 여기에는 Linux와 관련된 것이 없습니다. 대부분의 BSD에는 자체 패키지 관리자도 있습니다. Commercial Unices에는 패키지 관리자가 있습니다.

도대체 유닉스에만 해당되는 것도 아닙니다. Windows에만 소프트웨어를 설치하는 방법에는 6가지가 있으며 그 중 일부는 말하자면 패키지 관리자입니다. Microsoft는 NuGet 패키지 관리자를 만들었지만 .NET에서만 작동했기 때문에 커뮤니티는 Chocolatey 패키지 관리자를 만들었고 Microsoft는 WinGet 패키지 관리자가 있고, 앱을 설치하고 제거할 수 있는 Microsoft Store가 있고, Microsoft Installer가 있습니다. 또한 Microsoft Installer에만 MSI 패키지를 생성하는 데 필요한 약 12가지 도구가 있습니다. 타사에서만 가능하지만 Microsoft 자체에도 여러 도구가 있습니다.

하지만 또 다른 이유가 있습니다. 패키지 관리, 특히 종속성 관리는매우 어렵다문제는 해결되어야 하지만,엄청나게 간단한 것 같아요(이 질문은 좋은 예입니다.)

이 문제는 해결하기가 매우 어렵다는 사실은 거의 모든 사람이 문제가 발생하는 것을 직접 경험했다는 것을 의미합니다. 믿을 수 없을 만큼 단순해 보인다는 사실은 그것이 잘못되는 것을 직접 경험한 거의 모든 사람들이 "그건 멍청한 짓이야, 내가 더 잘할 수 있어"라고 생각할 것임을 의미합니다.

그리고,빵, 이제 N+1 패키지 관리 시스템을 갖게 되었습니다.

편집

모든 배포판이 이 "내부"를 공유하므로 여기서부터 시작하겠습니다. 모든 소프트웨어는 배포판의 일부로 선택되기 전에 어느 시점에서 컴파일됩니다. 올바르게 추측한 대로 완전한 컴파일된 프로그램에는 다음 중 하나 또는 모두가 포함될 수 있습니다.

• 라이브러리: 일반적으로 공유 객체 파일이나 아카이브로 저장됩니다. 바라보다.a 파일과 .so 파일의 차이점은 무엇입니까?
• 헤더 파일. 바라보다GCC 문서의 헤더 파일
• 실행 가능한 프로그램이라고도 알려진 바이너리 파일

패키지로 컴파일

다시 말하지만, 모든 배포판에는 패키지가 있고 모든 배포판에는 패키지 관리자가 있습니다. 혼란을 야기할 수 있다고 생각되는 부분은 다음과 같습니다.포장 형식 및 포장 내용은 포장 관리 시스템이 아닙니다.모든 배포판의 패키지 관리 시스템은 세 가지 부분으로 구성됩니다.

1. 패키지 형식(예: 컴파일된 섹션의 항목이 저장되거나 정렬되는 방식)
2. 패키징 도구 - #1에 따라 컴파일된 프로젝트의 실행 파일/바이너리를 패키징합니다. 그러면 패키지가 생성됩니다.
3. 패키지 관리자 - #2의 도구를 반복적으로 호출하여 패키지의 실행 파일/바이너리를 조작합니다. 조작은 다음을 포함할 수 있는 작업을 의미합니다.
   • 설치/재설치
   • 이동하다
   • 구성 파일 업데이트
   • 설치된 모든 패키지 업데이트

패키지 관리자를 만드는 이유

패키지 관리자 이전에는 패키징 도구를 사용하여 패키지를 설치하는 것이 완벽하게 허용되었습니다. 이런 방식으로 패키지를 설치할 때 발생하는 문제는 다음과 같습니다.

1. Debian에 foo.deb패키지를 설치하고 시작했습니다.dpkg -i foo.deb
2. 다음 명령을 사용하여 foo.deb를 실행해 보았습니다.foo
3. 다음 오류 메시지와 함께 프로그램이 갑자기 종료됩니다.프로그램 foo에는 bar.so 파일이 필요하지 않습니다. 종료됩니다.
4. 이제 막혔고 실행이 필요하므로 foo1~3단계를 반복합니다.bar.deb
5. 다시 시도했는데 또 다른 오류가 발생했습니다.프로그램 표시줄에는 정적 라이브러리 baz.a가 필요합니다.그런 다음 프로그램이 종료됩니다.

패키지 관리자에게 패키지

이제 나는 6 단계 아래로 내려갔고 정말 화가 났어요 foo. 나를 위해 모든 것을 할 수 있는 프로그램이 있다면 정말 좋을 것 같아요. 이것이 패키지 관리자의 주요 업무입니다. 패키지 관리자는 메모리에 종속성 그래프를 그려 필요한 foo것과 그렇지 않은 것을 bar계산 합니다 . 종속성이 없는 패키지를 찾을 때까지 계속 계산하고 역방향으로 작업한 다음 필요한 패키지가 설치되어 있는지 확인합니다. 패키지가 설치되고 필수 구성이 활성화되면 차트에 표시되고 다음 패키지가 검색됩니다. 요구 사항을 충족하기 위해 검색된 다음 패키지를 업데이트해야 하는 경우 패키지 저장소를 쿼리하고 업데이트된 버전을 추가합니다. 와, 이제 방금 추가한 업데이트에도 필요하기 때문에 다이어그램을 다시 시작하거나 새 분기를 다시 그려야 합니다.barbaz

이 프로세스는 패키지가 설치되거나 업데이트될 때마다 계속해서 반복됩니다.

명명 차이점

기술적으로 패키지 관리자 간에는 차이가 없습니다. 각 관리자는 자신이 설치된 시스템에서 이전에 설명한 기능을 훌륭하게 수행합니다. 언급하신 대로 FH 표준은 요구 사항이 충족되면 매우 유연하므로 모든 배포판은 일부 패키지 관련 항목을 조정하기로 결정하고 패키지 관리자에서 이 작업을 수행합니다. 컨셉이 제안되었을 때는 주로 브랜드 인지도를 위한 것이었습니다. R은 .rpmRed Hat을 의미하고 세 글자의 .deb확장자는 Debian의 약어입니다.

자신만의 패키지를 컴파일하는 것이 위험한 이유

연결한 질문에서 최신 버전을 찾고 있지만 libuv해당 버전은 Ubuntu Repo에서 사용할 수 없습니다 jammy. 사용할 수 없기 때문에 새 버전을 컴파일하는 것이 유일한 옵션이지만 최선의 옵션은 아닙니다.

• 소프트웨어를 컴파일할 때 패키지 관리자는 패키지를 컴파일한 후에 패키지를 설치하지 않기 때문에 패키지 관리 시스템은 컴파일한 내용을 관리할 수 없습니다. 간단히 말해서, 이제 관리되지 않는 소프트웨어를 호스팅하는 것 외에도 관리되지 않는 소프트웨어를 관리해야 하는 번거로움이 추가되고 패키지 관리자가 제공하는 기능이 손실됩니다. 비록 1개의 패키지에 대해서라도 말이죠.
• 컴파일된 패키지가 저장되었는지 확인하세요.~에클라이언트의 웹사이트. 위의 사항에 따라 관리되지 않는 소프트웨어로 호스트 운영 체제를 오염시키지 않는 것이 항상 호스트 운영 체제에 가장 좋습니다.
• 이는 해당 프로그램에 대한 모든 호출이 로컬이라는 것을 의미합니다. /bin고객을 언급할 때 호스트를 언급하는 실수를 저지르지 마세요./bin