저는 계약직에서 Centos 7 상자의 관리를 담당하고 있습니다. 저는 실제로 개발자에 가깝고 Linux 관리자에 가깝지 않습니다. 그러니 양해해 주시고 제가 5살인 것처럼 설명해주세요.
우리가 작업 중인 앱 중 하나에는 다음과 같은 것이 필요했습니다.pdftk. 불행히도 이에 대한 종속성은 libgcj라는 것입니다. 나는 libgcj가 더 이상 사용되지 않는 것으로 간주되어 더 이상 새로운 Centos 7과 함께 "배송"되지 않는다는 것을 읽었습니다.
그래서 저는 이렇게 했습니다:
wget http://mirror.centos.org/centos/6/os/x86_64/Packages/libgcj-4.4.7-11.el6.x86_64.rpm
wget https://www.pdflabs.com/tools/pdftk-the-pdf-toolkit/pdftk-2.02-1.el6.x86_64.rpm
rpm -ivh --nodeps libgcj-4.4.7-11.el6.x86_64.rpm
yum install pdftk-2.02-1.el6.x86_64.rpm
그리고 예, pdftk는 이제 작동합니다. 그러나 나는 이것저것 읽어보면서 이것이 나쁜 생각이었다고 판단했습니다. 왜 이것이 어리석은 일인지에 대한 이유는 제시되지 않았습니다. 그렇다면 내가 왜 이 일을 하지 말았어야 했는지에 대해 누가 밝혀줄 수 있을까요? 아니면 지금 취해야 할 조언이나 예방 조치를 알려주시겠습니까? 이것이 우리의 상자를 깨뜨리지 않을 것이라는 것을 알 때까지 서버를 다시 시작하거나 업데이트를 설치하는 것이 두렵습니다.
미리 감사드립니다.
답변1
이것이 완전한 대답은 아니지만 지금까지 아무도 이 절차가 나쁜 생각이 아닐 수 있는 이유를 제시하지 않았습니다.
특정 버전의 패키지는 외부 라이브러리에서 제공하는 기능에 의존합니다. 이러한 라이브러리는 시간이 지남에 따라 변경되며, 그 과정에서 동작이 변경되거나 기능이 완전히 제거될 수도 있습니다. EL6에서 EL7로 이동하는 것은 상당히 큰 단계이므로 일반적으로 설치된 패키지 버전에서 작동하지만 전체 범위에서는 작동하지 않는 새 버전의 패키지/라이브러리 XYZ가 있을 수 있습니다.
귀하의 경우 pdftk는 일반적으로 예상대로 작동할 수 있지만 일부 특별한 경우에는 설치된 나머지 패키지와 작동하지 않는 함수 호출이 있을 수 있으므로 충돌이 발생하거나 예기치 않게 작동할 수 있습니다. 그러면 이러한 잘못된 행동의 출처를 평가하는 것이 매우 까다로워질 것입니다.
이렇게 하지 않는 데에는 다른 이유가 많이 있을 수 있지만 이것이 제가 가장 먼저 생각하는 것이며, 생산 시스템의 안정성이 핵심입니다. 따라서 특정 OS 릴리스용으로 설계되지 않은 버전을 혼동하지 않을 것입니다. 적어도 철저한 테스트 없이는 그렇지 않습니다.
답변2
주요 문제는 다음과 같습니다.
지원되지 않습니다
gcc-java일부 명령줄을 사용하여 , libgcj을 libgcj-devel시스템으로 가져올 수 있습니다 . 그러나 이 소프트웨어는 CentOS 7에서 지원되지 않습니다. 지원되지 않는 구성을 사용하면 문제가 발생할 가능성이 더 높습니다. 이는 우리를 다음으로 이끈다...
Rackspace는 이를 지원하지 않습니다.Ubuntu보다 CentOS를 사용하면 물론 더 나은 엔터프라이즈 지원이 제공된다는 이점이 있습니다. 이와 같이 지원되지 않는 구성을 사용하면 모든 것이 손실됩니다. 따라서 Rackspace에 "pdftk를 포함한 XYZ 소프트웨어가 포함된 서버를 만들어 주세요"라고 말하면 그들은 "아니요"라고 말할 것입니다.
다른 사람이 지원되는 구성의 CentOS 7에서 작업하기 위해 pdftk가 필요한 경우 Java 부분을 다시 작성하여 CentOS 7에 허용되도록 하는 포크가 존재합니다. 우리 회사에는 이것이 필요하고 저는 이를 수행할 시간이 없으므로 작업을 시작합니다. 이 일에 대한 현상금. 이 현상금과 포크를 확인하도록 초대합니다.https://github.com/fulldecent/pdftk