포장해볼까 고민중이에요MATLAB(독점 소프트웨어) PKGBUILD를 생성하여 설치, 종속성 및 충돌을 처리하는 Arch Linux용. 모든 것을 로컬 디렉터리에 저장하고 많은 외부 패키지가 필요하지 않은 표준 Matlab Linux 설치 프로그램을 사용하세요.
즉, 완전한 JRE뿐만 아니라 많은 표준 라이브러리 파일(예: libgcc_s.so 및 libstdc++.so)을 제공합니다. 이러한 유형의 파일을 제거하고(아마도 링크로 대체) 다른 패키지 종속성에 의해 제공될 수 있습니까?
답변1
Matlab 설치에 포함된 동일한 버전이라고 가정하면 삭제가 문제가 되고 링크로 교체하는 이유를 이해할 수 없습니다. 하지만 왠지 자신을 위해 많은 일을 하고 있는 것 같은 느낌이 듭니다.
내가 Matlab과 같은 여러 버전의 독점 소프트웨어 패키지를 유지 관리하는 그룹을 지원했을 때 우리 그룹은 해당 패키지를 별도의 디렉토리에 설치하고 다음과 같은 것을 사용했습니다.modules사용자가 이러한 패키지를 사용할 수 있도록 사용자 환경을 전환하려는 경우 사용자 환경 관리를 유지합니다.
다음 제목의 U&L Q&A를 참조하세요.동일한 상위 디렉터리 아래에 여러 하위 디렉터리를 PATH에 추가여기에서는 $PATH시스템 환경 변수를 관리하기 위한 다양한 전략을 논의합니다. 이와 동일한 전략은 거의 모든 환경 변수에도 적용될 수 있습니다. 이는 독점 애플리케이션의 기능을 제어하는 요소인 경우가 많습니다.
답변2
나노력하다제가 설치하고 있는 AUR에서 PHP App Engine 패키지를 유지하려면 /opt거기에 독립 실행형 Matlab 패키지(예: /opt/matlab)를 넣고 실행 파일을 다시 심볼릭 링크하고 /usr/bin다른 항목을 다시 링크해야 합니다 /usr/share/applications.
나는 아치용 바이너리를 다시 패키징하는 다른 패키지를 살펴볼 것입니다. 그림드롭 박스또는구글 크롬가방. Chrome 패키지는 특히 Debian 바이너리에 의존하므로 아치에 설치할 때 Debian 세부 정보를 삭제합니다.
반면, /opt/matlab공통 라이브러리와 JRE를 제거하는 대신 모든 것을 있는 그대로 두면 종속성이 변경될 때마다 중단되지 않거나 다시 테스트하고 다시 패키징해야 하는 작동하는 Matlab 종속성을 갖게 될 가능성이 더 높습니다. .
Matlab 전체 패키지와 Matlab 최소 패키지의 두 가지 버전을 제공할 수 있습니다.
답변3
대형 애플리케이션에는 두 가지 이유로 번들 라이브러리가 함께 제공됩니다. 한 가지 이유는 사용자가 모든 라이브러리를 추적하고, 배포판에 라이브러리가 포함된 패키지를 찾고, 올바른 버전이 있는지 확인하는 등의 작업을 하지 않아도 되기 때문입니다. 배포판은 시간이 지남에 따라 특정 시점에 서로 다른 라이브러리 버전을 제공하는 경우가 많기 때문에 모든 배포판에서 작동하는 바이너리 패키지를 유지 관리하는 것은 까다롭습니다. 패키지가 특정 배포판의 특정 버전에서 작동하는 경우 배포판 버전에 의존하는 것은 문제가 되지 않습니다. 그러나 Arch Linux에서는 안정적인 릴리스가 없기 때문에 최소한 빠르게 변화하는 라이브러리를 번들로 묶지 않으면 패키지를 자주 업데이트해야 합니다.
라이브러리를 번들로 묶는 또 다른 이유는 프로그램이 특정 라이브러리 버전에 의존하는 경우가 있기 때문입니다. 원칙적으로 라이브러리에는 두 부분 버전 번호가 있습니다. ABI가 호환되지 않는 방식으로 변경될 때마다 변경되는 주 버전 번호와 변경 사항(예: 버그 수정 또는 호환되지 않는 새 기능)이 변경될 때마다 변경되는 부 버전 번호입니다. 변경되었습니다. 이전 버전과의 호환성이 깨졌습니다). (많은 라이브러리에는 MAJOR.MINOR 형식의 버전 번호가 있지만 이것이 보편적인 것은 아닙니다.) 주요 버전이 다른 라이브러리 바이너리는 서로 다릅니다.소네임, 함께 설치될 수 있도록 하는 반면, 마이너 버전만 다른 라이브러리 바이너리는 동일한 soname을 가지므로 동적 링크에서는 하나만 찾을 수 있습니다. 프로그램이 버전 1.2에 대해 구축되고 테스트되었지만 버전 1.3이 있는 경우 프로그램은~해야 한다아직도 일하고 있어요. 그러나 때때로 프로그램은 ABI의 일부가 아니고 1.3에서 손상될 수 있는 문서화되지 않은 인터페이스를 사용합니다. 가능한 모든 라이브러리 버전 조합으로 테스트하는 것은 지원에 있어서 악몽이 될 것이기 때문에 바이너리 배포자는 모든 사용자가 동일한 라이브러리 버전을 사용하는 것을 선호합니다(일부 시스템 라이브러리, 특히 libc 제외).
1애플리케이션 바이너리 인터페이스: 컴파일된 라이브러리와 컴파일된 프로그램 간의 인터페이스 사양입니다.