☰

휴대용 Linux 상용 폐쇄 소스 프로그램을 배포하는 방법은 무엇입니까? [폐쇄]

tag-icon • tag-icon dynamic-linking shared-library deployment
휴대용 Linux 상용 폐쇄 소스 프로그램을 배포하는 방법은 무엇입니까? [폐쇄]

먼저 비슷한 질문을 찾았습니다.휴대용 Linux 애플리케이션을 만드는 방법은 무엇입니까?그러나 이것이 내 문제를 실제로 해결하지는 못합니다. 응용 프로그램을 이식 가능하게 만들기 위해 컴파일하는 방법에 대한 것이 더 중요합니다. 나는 이미 수행 방법을 알고 있습니다(적어도 나는 알고 있다고 생각합니다). 배포에 대해서는 덜 설명합니다. 방법.

이것이 내 상황입니다. 우리는 고객의 문제를 해결하기 위해 고용되었으므로 고객에게 판매할 목적으로 비공개 소스 애플리케이션을 개발할 것입니다. 그러나 우리는 그것이 어디에서 실행될 수 있는지에 대한 세부 정보를 얻지 못했습니다. 즉, 배포판, 커널 버전 또는 기타 사항을 의미합니다. 작업은 매우 간단하며 낮은 수준의 드라이버나 이식성을 복잡하게 만드는 어떤 것에 의존하지 않습니다. 그러나 우리는 여러 타사 라이브러리에 의존합니다. 다음은 간단한 종속성 체계입니다.

app --+-- libA
      |          +-- lib1
      +-- libB --+-- lib2
                 +-- lib3

그 중 libA, B 및 lib1, 2, 3은 적절한 라이선스(LGPL, ASL 및 BSD)가 있는 오픈 소스 프로젝트입니다. 컴파일 후, 우리 프로그램의 공유 종속성은 libA, libB, lib1, lib2, lib3 및 libc, libm, libz, libstdc++, libpthread 등과 같은 여러 시스템 라이브러리가 됩니다. 모든 것이 동적으로 연결되어 있습니다.

이제 대상 배포판이 없으므로 이를 모든 패키징 시스템(예: .deb 등)과 독립적으로 만들고 싶습니다. 직접적인 종속성(libA 및 libB)은 일반적이지 않으므로 애플리케이션과 함께 제공하는 것이 확실한 선택입니다. lib1,2,3은 실제로 더 일반적이지만(즉, 그 중 하나가 libpng임) 대상 시스템에 설치될지는 아직 확실하지 않습니다. 우리는 그것들을 모두 최종 패키지에 포함하기로 결정했습니다.

우리는 시스템 라이브러리로 무엇을 해야할지 모릅니다. 우리는 이 문제를 어떻게 처리해야 합니까? 우리는 그들이 올바른 라이브러리를 갖고 최선을 다할 것이라고 가정합니까? 이 경우 라이브러리 중 하나가 변경되고 애플리케이션 작동이 중지되면 1~2년 후에 어떻게 되나요?

이 모든 것(libstdc++, glibc 등)을 소프트웨어와 함께 배포해야 합니까? 이는 옳지 않다고 생각되며 라이센스 조항을 위반할 수도 있다고 생각합니다. 나는 과거에 이러한 라이브러리 중 [적어도] 일부의 자체 복사본을 가지고 있는 일부 프로그램을 사용한 적이 있다는 것을 알고 있으며, 이 프로그램은 내 시스템에 있는 것보다 오래된 버전이어서 이를 교체했기 때문에 실제로 관심을 끌었습니다. 모든 것이 작동을 멈췄습니다(우연히 이것을 발견했습니다).

이런 상황은 보통 어떻게 처리되나요?

답변1

Linux에서 이식 가능한 바이너리 실행 파일을 구현하는 엄격하게 올바른 방법은 다음과 같습니다.리눅스 표준 라이브러리그리고 그것의상세사양. LSB는 특정 라이브러리 버전(또는 해당 버전과의 호환성)을 지정하여 호환 가능한 배포판 전체에서 바이너리 호환성을 생성하기 위한 것입니다. LSB(또는 적어도 이전 버전)는 다음과 같이 공식화됩니다.ISO/IEC 23360. LSB 라이브러리(및 함께 제공되는 라이브러리)에 대해서만 링크하는 프로그램을 구축하면 이러한 모든 시스템 간에 이식 가능합니다.

LSB는 패키지의 RPM 형식을 지정하므로 하나만 생성하면 됩니다(엄격히). 패키지 관리자와의 통합을 포기한다면 타르볼로 충분합니다.

귀하에 대한 몇 가지 구체적인 사항은 다음과 같습니다.

우리는 그들이 올바른 라이브러리를 갖고 최선을 다할 것이라고 가정합니까?

상당히 간단한 LSB 호환 프로그램은 아마도 많은 시스템에서 있는 그대로 실행될 것이므로 그렇게 할 수 있습니다.

또한 일부 배포판에서는 RHEL 및 SUSE를 포함하여 LSB 준수를 제공하려고 시도합니다. 일부는 적절한 종속성을 가져오는 특정 패키지를 통해 이를 제공합니다. 예를 들어 데비안에는세트lsb이는 다른 여러 가지를 끌어오고 lsb-core차례로 적절한 종속성을 끌어옵니다. 소프트웨어를 실행하려면 대상 시스템에 이러한 패키지를 설치해야 할 수도 있습니다.

LSB는 더 이상 예전만큼 인기가 없으며 많은 시스템과의 공식적인 호환성이 감소했지만 실제로는 상당히 광범위한 응용 프로그램으로 이식될 수 있습니다. 규정 준수를 갈망하는 일부 시스템조차도 좀 더 모호한 점을 놓칠 수 있지만 일반적인 목적을 위해 이는 일반적으로 중요하지 않습니다(그리고 동일한 프로그램이 아마도 다음 시스템에서 실행될 것입니다).아니요LSB를 준수하도록 노력하세요.)

이 경우 라이브러리 중 하나가 변경되고 애플리케이션 작동이 중지되면 1~2년 후에 어떻게 되나요?

앱 작동이 중지되면 앱 작동도 중지됩니다. 이는 비즈니스 프로세스 문제입니다.

이 모든 것(libstdc++, glibc 등)을 소프트웨어와 함께 배포해야 합니까?

아마도 그렇지 않을 것입니다. 특히 libc의 경우 시스템에서 여러 버전을 동시에 사용할 때 런타임 호환성 문제가 발생할 수 있습니다. 그러나 번들링에 더 적합한 다른 libc 구현이 있습니다.

대부분의 라이브러리는 성공적으로 번들링될 수 있지만 라이브러리 프로비저닝은 유지 관리 및 보안 문제가 되는 경우가 많으므로 가능하면 이를 피하는 것이 좋습니다. 라이브러리에서 버그나 보안 결함이 발견되면 각 복사본을 추적하고 교체 패키지를 받는 것보다 시스템의 한 위치(릴리스로 문제가 해결될 위치)에서 업데이트하는 것이 더 쉽고 안정적입니다! ).

보다 실용적인 단계로 고객에게 어디에서 실행하고 싶은지 물어볼 수도 있습니다. 지나치게 열정적일 수도 있습니다.

답변2

실제로 당신은해야합니다일부가장 일반적인 Linux 배포판(및 버전)용 바이너리 패키지(예: .debDebian 및 Ubuntu, Fedora용) .rpm분명히 Fedora와 Ubuntu, 그리고 Debian Jessie와 Ubuntu 16.04에 대해 서로 다른 패키지를 만들어야 할 것입니다. 하지만,때때로Ubuntu용 패키지는 일부 (특정) Debian에 설치될 수 있으며 그 반대의 경우도 마찬가지입니다.

그러나 우리는 그것이 어디에서 실행될 수 있는지에 대한 구체적인 정보를 얻지 못했습니다. 즉, 배포판, 커널 버전 또는 기타 사항을 의미합니다.

이 문제에 대해서는 고객과 논의해야 합니다.

이 경우 라이브러리 중 하나가 변경되고 애플리케이션 작동이 중지되면 1~2년 후에 어떻게 되나요?

바이너리 패키지의 업데이트된 변형을 빌드하고 릴리스해야 하며 이를 위해 노력과 비용을 소비하게 됩니다.

기술적으로나 법적으로 가능한 경우 특정 라이브러리를 정적으로 링크할 수 있습니다(LGPL 라이센스는 동적 링크 또는 클라이언트 시스템에서 정적으로 재링크하는 기능을 권장한다는 점을 기억하십시오). 예를 들어 libstdc++버전보다 버전에 더 민감하므로 정적 및 동적으로 링크 libc할 수 있습니다 . 실제로 YMMV.libstdc++libc

있습니다.일부특정 시스템 라이브러리 버전은 실제로 작동할 수도 있고 작동하지 않을 수도 있습니다. 일부 라이브러리는 시스템 리소스를 특정 방식으로 사용하므로 세부 정보가 중요합니다.

추신. 고객과 더 많은 논의를 하고 무료 소프트웨어(오픈 소스)를 만들겠다고 제안해야 할 수도 있습니다. 일부 고객은 이것을 선호할 수도 있습니다.

관련 정보