여러 Linux 배포판에 대해 바이너리 전용 애플리케이션을 게시하는 데 선호되는 방법은 무엇입니까?

Question

배포하려는 비공개 소스 Linux 애플리케이션이 있습니다.이 애플리케이션은 wxWidgets/GTK를 사용하므로 이 애플리케이션이 의존하는 공유 라이브러리(60개 이상)의 거대한 목록이 있습니다.

애플리케이션을 게시하고 최대 배포판 수를 지원하는 데 선호되는 방법은 무엇입니까?

• 지원되는 각 배포판에 대해 애플리케이션을 빌드하고 별도로 게시하는 것입니까?이는 빌드가 복잡하다는 단점이 있으며(chroot 및 배포판별 빌드) 지원되는 배포에서만 작동합니다.

• 설치 프로그램에 모든 공유 라이브러리를 추가하고 이를 LD_LIBRARY_PATH 환경 변수(예: VMware)와 함께 사용하는 것입니까?이는 설치 프로그램의 크기가 커지는 단점이 있습니다.

• 완전히 정적인 애플리케이션을 구축하는 것인가요?일부 라이센스가 중단될 수 있으므로 이는 불가능합니다.

• 그것과 다른 옵션이 혼합되어 있습니까?대부분의 상용 공급업체는 자체 그래픽(바람직하게는 GTK 기반) 애플리케이션을 어떻게 게시합니까?

Answer 1

당신은 Linux 표준 베이스.이는 귀하의 위치에 있는 사람들을 돕기 위해 특별히 설계되었습니다.이는 제3자 애플리케이션 개발자가 의존할 수 있는 환경을 정의합니다. 따라서 libc 및 기타 라이브러리의 설정된 버전이 있고 특정 프로그램 및 디렉토리가 알려진 위치에 있습니다.모든 주요 Linux 배포판은 LSB를 지원합니다.

즉, 고객이 익숙한 패키지 관리 도구를 사용하여 앱을 관리할 수 있도록 각 주요 배포판에 대해 결과를 구체적으로 패키지해야 합니다.

Answer 2

기본적으로 두 가지 방법이 있습니다. 원하는 경우 둘 다 선택할 수 있습니다.

첫 번째 방법은 공통된 방식이며 그와 같은 방식입니다. lib/ subdirectory를 만들고 사용하십시오 LD_LIBARY_PATH 필요한 모든 공유 라이브러리를 포함하십시오. 이는 사용자로부터 통증이없는 경험을 보장하지만 설치 업체를 더 크고 메모리 발자국을 더 크게 만듭니다. 기존 라이브러리를 재사용하려고 시도조차하지 않을 것입니다.

두 번째 방법은 분포 패키지를 제공하는 것입니다. 이것들은 일반적으로 만들기가 어렵지 않으며 분배와 잘 통합 될 것이며, 고객에게 훨씬 더 환영받는 것처럼 보일 것입니다. 2 개의 단점은 다음과 같습니다. 각 배포에 대해이 작업을 수행해야합니다 (Debian, Ubuntu, Suse, Redhat은 아마도 좋은 출발 일 것입니다). 시간이 지남에 따라 일부 라이브러리는 더 이상 사용할 수 없습니다. 특정 버전에서는 사용자에게 종속성 문제가 발생합니다.

Answer 3

설치 프로그램에서 어떤 라이브러리가 설치된 라이브러리를 확인한 다음, 그렇지 않은 바이너리를 다운로드하십시오.

사용자의 추가 편안함을 위해 인터넷에 연결되지 않은 경우 설치 프로그램이 웹 사이트에 입력 할 수있는 키를 생성하여 Zip Archive를 수신 한 다음 설치자에게 공급할 수있는 키를 생성하도록하십시오.

최대한 편안하게 대상 배포판에서 사용할 수있는 라이브러리를 확인하고 사용자에게 표준 관리 도구를 사용하여 설치하도록 요청하십시오. 그렇게하면 동일한 라이브러리의 다른 버전으로 컴퓨터를 오염시키지 않습니다.

즉, 귀중한 코드를 링크 라이브러리에 넣은 다음 소스 패키지의 이진 블로브로 제공하는 것이 더 똑똑 할 수 있습니다. 이렇게하면 코드는 순수한 바이너리에있는 것처럼 보호됩니다. 사용자는 물건에 대해 걱정하지 않고도 좋아하는 시스템에서 접착제 코드를 컴파일 할 수 있습니다.

내 말은 : UI를 설정하는 코드의 일부는 얼마나 가치가 있습니까? 누군가가 그것을 훔칠 때 얼마나 많은 것을 잃을 것입니까?