Linux 개발자가 범용 패키징 형식을 만들 수없는 이유는 무엇입니까?

공급 업체 바이너리 패키지 형식 선택은 Murphy 's Law 형식으로 결정됩니다 . 사용 하지 않는 모든 배포판 에는 패키지가 있습니다. (일반 : 소프트웨어 스택의 배포 종속성을 충족시키는 배포가 없습니다).

이것이 "한 번 빌드하고 어디에서나 실행"패키지 형식의 출현을 보지 못한 정치적인 문제입니까, 아니면 더 깊은 것입니까?

이것에 대해 Joel Spolsky 를 인용하는 것이 적절 해 보입니다 .

(그런데, 정치적이지만 비용이 많이 드는 블로그 신디케이션 피드 형식의 세계를 따르는 사람들에게는 동일한 일이 발생하는 것을 볼 수 있습니다. RSS는 여러 가지 버전, 부정확 한 사양 및 많은 정치적 싸움, Atom이라는 또 다른 형식을 만들어 모든 것을 정리하려는 시도로 인해 RSS의 여러 버전과 하나의 Atom 버전, 부정확 한 사양 및 많은 정치적 싸움 이 발생했습니다. 세 번째 대안을 만들어 두 개의 반대 세력을 통합하려고 할 때, 당신은 세 가지 반대 세력으로 끝납니다. 당신은 아무것도 통일하지 않았고 실제로 아무것도 고치지 않았습니다.)

(강조 추가)

Linux 용으로 두 개 이상의 패키징 시스템이 있습니다. 실제로 좋은 일입니다. 단일 시스템은 단순히 세 번째 시스템을 만듭니다.

여기에는 여러 가지 이유가 있으며 사물을 원근법으로 만들기 위해 약간의 역사가 있습니다.

"Linux"에 관해 이야기 할 때 일반적으로 언급하는 것은 많은 다른 Linux 배포판 중 하나입니다 . "Linux"는 실제로 운영 체제 커널입니다.

Linux의 원래 목표는 PC (처음에는 386)에서 실행되는 Unix 기반 시스템을 만드는 것이 었습니다. 첫 단계는 커널 자체를 만드는 것이 었습니다. Linus Torvalds 가 커널에서 작업 하는 동안 Richard Stallman 은 GNU (GNU 's Not Unix) 프로젝트 에서 자신의 Free Unix 시스템에서 작업했습니다 . 간단히 이야기하자면, GNU에는 관련 유틸리티 (C 컴파일러 / 라이브러리 / 빌드 도구, 쉘, 텍스트 편집기 등)가 있지만이를 실행할 코어가없고 Linux에는 코어가 있지만 유틸리티는 없었기 때문에 두 가지가 다소 수렴되었습니다. 대중에게 유용하게 사용할 수 있습니다.

이 수렴은 공식적으로 GNU / Linux로 알려졌습니다. 많은 배포판이 여전히 GNU / Linux 배포판이라는 것을 알 수 있습니다.

GNU / 리눅스의 자유롭고 개방 된 특성으로 인해 누구나 GNU / 리눅스를 선택하여 특정 취향에 맞는 번들 시스템을 만들 수 있습니다. 그 결과 다양한 구성 방법의 다양한 스트림이 이러한 시스템을 생성하는 데 사용되었으며, 각 시스템에 맞는 수 많은 패키지 관리 시스템을 생성하는 부작용이있었습니다.

각각의 서로 다른 완전한 시스템에는 수년에 걸쳐 강력한 추종자들이 있었기 때문에 오늘날 우리가 가지고있는 것 : RPM , APT / dpkg 및 Gentoo 's Portage 와 같이 널리 사용되고, 뿌리가 많고 안정적인 패키지 관리 시스템이 있습니다.

Autopackage 와 같은 프로젝트 가 문제를 해결하려고 시도하고 있지만 지원되는 다양한 패키지 관리 시스템의 지속적인 발전은 따라야 할 많은 목표가 있음을 의미합니다.

일부 소프트웨어 공급 업체가하는 일은 특정 바이너리와 의존성 복사본을 특정 시스템에서 작동하는 하나의 큰 패키지로 묶는 것입니다.

동일한 패키지 형식을 갖는 것은 어쨌든 도움이되지 않습니다. 다른 배포판에서는 동일한 패키지를 사용할 수 없습니다. 동일한 배포판의 다른 버전에서도 종종 사용할 수 없습니다. 심지어 패키지를 빌드하더라도 동일한 문제가 발생할 수 있습니다.

패키지를 설치하려면 패키지를 빌드하는 동안 형성된 종속성을 충족해야합니다. 패키지를 빌드하려면 빌드 종속성을 충족해야합니다. 그리고 이런 것들이 변합니다. 변경 사항을 구현할 수 있도록 변경 한 후에 작동하도록 수정할 수있는 패키지 만 지원하는 것이 더 쉽습니다.

모든 종속성이 동일하면 다른 배포 또는 동일한 배포의 다른 버전이 아닙니다.

"발명되지 않은 증후군"이라고 생각합니다. 데비안의 패키징 시스템은 RedHat보다 오래되었지만 여러면에서 우수하지만 RedHat 전환은 결코 볼 수 없습니다. 대신, "apt-rpm"을 사용하는 많은 사람들이 rpm 파일을 사용하여 apt의 장점을 제공하려고합니다.

.deb로 이동하십시오 :-)

zero-install 및 autopackage 와 같은 몇 가지 임시 형식이있었습니다 . 불행히도 아무도 견인력을 얻지 못했습니다.

나는 cletus, Wayne, iny가 이것에 꽤 잘 대답했다고 생각합니다. 나는 그것을 정말로 추가하고 싶습니다. 별거 아닙니다. 젠투 (portage), SUSE (rpm / zypper), OpenBSD (packages and ports)가있는 혼합 환경에서 일하고 있습니다. 그중 하나에 패키지를 설치하는 것은 어렵지 않으며 실제로 어떤 형식을 사용하고 있는지 상관하지 않습니다.

패키징 소프트웨어의 관점에서 보면 그리 어렵지 않습니다. RPM 기반 배포판 또는 deb 기반 배포판 인 Gentoo는 실제로 소프트웨어를 구축하고 일부 메타 데이터를 추가하는 레시피를 제공합니다. 패키지하려는 빌드 시스템이 완전히 미친 것이 아니라면 일반적으로 패키지를 만들기 위해 영광스러운 쉘 스크립트를 작성하는 것보다 약간의 시간이 걸립니다.

타르 볼에는 항상 정적으로 컴파일 된 바이너리가 있습니다 .... ;-)

"Linux"에 대한 표준 이진 인터페이스는 커널이기 때문에 정의가 없습니다. 이상한 점은 소프트웨어 스택이 커널 이상과 인터페이스해야하므로 수백 개의 서로 다른 소스 트리간에 표준 ABI를 유지 관리해야한다는 특별한 문제가 있다는 점입니다.

좋은 패키징 도구 라는 주제에서 데비안 GNU / 리눅스가 이진 패키징 형식이기 때문에 선호합니다. 표준 도구 및 응용 프로그램에 대한 요구의 90 %를 지원했습니다. 나머지 10 %는 비 무료 구성 요소 또는 버그가있는 공유 라이브러리 종속성으로 인해 소스에서 빌드됩니다. 이러한 응용 프로그램을 배포해야 할 때 프로덕션 클러스터에 대한 사용자 지정 이진 파일을 작성합니다.

한 번만 빌드하려면 모든 사람이 몇 가지 중요한 기능이 필요한 동일한 배포를 사용하지 않고 어디서나 패키지 형식을 실행하십시오.

• 두 사람 / 배포가 동일한 이름의 다른 패키지를 독립적으로 만들 수 없도록 전역 적으로 고유 한 패키지 이름 지정.

• 패키지 요구 사항이 충돌 할 때 다른 버전의 라이브러리를 병렬로 설치 배포판은 사용할 각 라이브러리의 버전을 결정하고 모든 패키지가 해당 버전을 사용하도록합니다. 여러 배포에서 작동하는 시스템은보다 유연해야합니다.

Zero Install 은 다음 기능을 모두 제공합니다.

• 이름은 URI입니다 (예 : http://rox.sourceforge.net/2005/interfaces/ROX-Filer ). 기본적으로 도메인 소유자 만 해당 네임 스페이스 내에 패키지를 만들 수 있습니다.

• 각 패키지의 각 버전은 자체 디렉토리에 있습니다. 각 응용 프로그램은 호환되는 버전과 함께 필요한 라이브러리 만 볼 수 있습니다.

예를 들어, 편집 애플리케이션은 다음과 같이 Python <3에 의존합니다.

<command name="run" path="Edit/AppRun">
  <runner interface="http://repo.roscidus.com/python/python">
    <version before="3"/>
  </runner>
</command>

참조 : http://www.osnews.com/story/16956/Decentralised-Installation-Systems

[참고 : 저는 0install 개발자입니다]