CentOS7 소프트웨어 설치 단계 및 전략에 대한 전체 분석

타사 소스에 소수의 패키지만 포함되어 있고 해당 패키지가 공식 소스 및 기타 사용된 타사 소스와 충돌하지 않는다고 확신하는 경우 타사 소스를 추가할 수 있습니다. 타사 소스에 많은 소프트웨어가 포함되어 있고 공식 소스 또는 EPEL 소스와 충돌할 가능성이 있는 경우 소스가 추가되지 않습니다. 소프트웨어 패키지에 복잡한 종속성이 없으면 소스에 rpm 패키지를 직접 설치하세요. 소프트웨어 패키지가 타사 소스의 다른 패키지에 의존하는 경우 포기하고 다른 방법을 찾으세요

타사 패키지 관리자

다른 배포판은 다른 패키지 관리자를 사용하고, CentOS는 yum을 사용하고, Ubuntu는 apt-get을 사용합니다. 최근 몇 년 동안 Linuxbrew, Gentoo Prefix 및 pkgsrc와 같은 일부 배포 독립적인 타사 패키지 관리자가 등장했습니다.

Linuxbrew

Linuxbrew는 OS X 플랫폼에서 매우 인기 있는 Homebrew에서 Linux로 포팅되었습니다. Linuxbrew는 시스템과 함께 제공되는 패키지 관리자에 대한 보충 자료로 사용할 수 있습니다. 그 기능은 다음과 같습니다:

모든 소프트웨어는 ${HOME}/.linuxbrew 디렉토리에 설치됩니다. 설치, 제거, 정보, 목록, 업데이트, 업그레이드 및 기타 기능에 필요한 소프트웨어 패키지가 없는 경우 소프트웨어 버전은 비교적 새로운 것입니다. 도서관에서 직접 쉽게 할 수 있습니다. 수식 만들기

시험해 본 후 함정 중 하나는 linuxbrew가 종속성 문제를 내부적으로 해결한다는 것입니다. 예를 들어, linuxbrew를 통해 터미네이터를 설치하려고 시도한 후 터미네이터가 Python에 의존한다는 것을 발견했습니다. Python이 이미 시스템에 설치되어 있지만 linuxbrew는 여전히 Python의 복사본을 설치하며 Python은 더 많은 것에 의존하기 때문에 더 많은 소프트웨어 패키지가 필요합니다. 집 아래에 설치되었습니다. 게다가 linuxbrew는 소스 코드에서 소프트웨어를 컴파일하므로 상대적으로 느립니다.

소스 코드 컴파일

대부분의 소프트웨어는 이전 방법을 사용하여 설치할 수 있습니다. 설치되어 있지 않으면 이 소프트웨어를 정말로 설치해야 하는지 스스로에게 물어봐야 합니다. 꼭 필요한 것이 아니라면 설치하지 마세요. 필요한 소프트웨어인 경우 수동으로 컴파일해야 합니다.

일반적인 소스 코드 컴파일에는 일반적으로 다음 단계가 포함됩니다. 물론 구체적인 상황은 사례별로 처리됩니다.

tar -xvf xxxx.tgz ./configure --prefix=/opt/xxxx make sudo make install

일반적으로 이러한 유형의 소프트웨어의 기본 설치 디렉터리는 /usr/local이며 최종 파일은 /usr/local의 bin, lib, share 및 man 디렉터리에 배치됩니다.

저는 개인적으로 이 방법을 별로 좋아하지 않습니다. 왜냐하면 소스 코드에서 컴파일된 소프트웨어로서 컴파일러가 소프트웨어를 관리할 의무를 완전히 져야 한다는 것을 의미하기 때문입니다. 이 배치 방법은 업데이트나 제거 시 많은 문제를 야기할 것입니다. 소프트웨어. 그래서 구성할 때 설치 경로를 수동으로 지정하기 위해 항상 접두사를 추가합니다. 소프트웨어를 제거하려면 /opt에서 해당 디렉터리를 삭제하면 됩니다. 업데이트하려면 해당 디렉터리를 먼저 삭제한 다음 다시 컴파일할 수도 있습니다. 이 작업에서 약간 번거로운 점은 소프트웨어의 bin 디렉터리를 PATH에 수동으로 추가해야 하고 LD_LIBRARY_PATH를 수정해야 할 수도 있다는 것입니다. 하지만 일반적으로 소스 코드를 컴파일해야 하는 소프트웨어는 거의 없기 때문에 큰 문제는 발생하지 않습니다.

컴파일 코드

알겠습니다. 사실 제목을 어떻게 정해야 할지 모르겠습니다. .

이전 섹션 "소스 코드 컴파일"은 주로 일부 대규모 소프트웨어 패키지에 중점을 둡니다. 이 섹션 "코드 컴파일"은 일부 고도로 전문적인 소규모 코드 패키지 처리를 나타냅니다. 예를 들어, 일부 소프트웨어 패키지가 컴파일된 후 실제로 필요한 것은 바이너리 파일뿐입니다. 현재로서는 이를 /opt에 설치할 필요가 없습니다. 적절한 방법은 자신의 HOME 아래에 bin 디렉토리를 만들고 해당 패키지를 추가하는 것입니다. .bashrc 경로를 추가한 다음 컴파일된 바이너리 파일을 이 디렉터리에 복사하세요.

mkdir ${HOME}/bin echo 'export PATH=${HOME}/bin:$PATH'>> ~/.bashrc

예를 들어, 내 ${HOME}/bin 디렉토리에 다음 파일이 있습니다:

distaz: 지구상 두 지점의 경도와 위도를 주고, 진원거리와 방위각을 계산합니다. pssac: GMT로 SAC 파일을 그립니다. rdseed: SEED 형식을 SAC 형식으로 변환 win2sac_32, catwin32: Hi-net 웹사이트에서 제공 Hi-net 데이터 처리 프로그램 st: sublime_text는 /opt 디렉토리에 설치되며 명령줄에서 sublime text 호출을 용이하게 하기 위해 여기에 소프트 링크가 설정됩니다. wlt.pl: 네트워크에 로그인하기 위한 학교 스크립트, 네트워크 수정. fk, fk.pl, syn, trav: Lupei Zhu 교수의 합성 지진계 계산 프로그램입니다. 실제로 필요한 소스 코드는 이 세 개의 실행 파일과 Perl 스크립트뿐입니다. matlab: matlab을 가리키는 소프트 연결

바이너리 파일을 bin에 넣지 마세요. 일반적으로 사용되는 일부 명령이나 매우 일반적인 도구만 여기에 넣어야 합니다.

자체 포함 소프트웨어

여러 모듈이나 패키지로 구성된 소프트웨어 유형이 있습니다. 이렇게 많은 모듈을 관리하려면 자체 모듈/패키지 관리자가 필요합니다. 그 중에는 TeX, Perl, Python이 있습니다. 이러한 유형의 소프트웨어의 경우 수많은 모듈이 가장 큰 장점이자 가장 가치 있는 리소스이므로 일반적으로 다음과 같은 이유로 수동으로 설치하도록 선택합니다.

시스템 소스에 소프트웨어의 모든 모듈이 포함되는 것은 불가능합니다. 시스템 소스의 소프트웨어 모듈 업데이트는 최신 버전보다 훨씬 뒤떨어집니다.

이로 인해 모듈 관리에 혼란이 생길 ​​수 있습니다. 반면, 소프트웨어 자체 패키지 관리를 사용하여 모듈을 설치할 경우 해당 모듈이 설치된 다른 모듈의 최신 버전에 따라 달라질 수 있습니다. 시스템 yum을 통해 모듈 설치에 실패할 수 있습니다.

따라서 이러한 유형의 소프트웨어의 경우 일반적으로 별도로 설치되며 자체 패키지 관리자를 사용하여 모듈을 관리합니다.

TeXLive: TeXLive iso 이미지 파일을 통해 설치, 자체 tlmgr 관리 패키지 사용 Perl: plenv를 통해 최신 버전의 Perl 설치, plenv와 함께 제공되는 cpanm을 사용하여 모듈 설치 Python: pyenv를 통해 최신 버전의 Python 설치, Python pip 설치 모듈과 함께 제공되는 것을 사용하세요

예외

규칙에는 항상 예외가 있습니다.

mosquito-myrepo는 중국어 입력 방법, QQ, Fetion, Weizhi Notes, Youdao Dictionary, Baidu Cloud 및 여러 오디오 및 비디오 플레이어를 포함하는 비공개로 유지 관리되는 소스입니다. 나는 이 소스에 대해 애증의 태도를 가지고 있습니다. 이 소스는 중국 사람들에게 필요한 많은 소프트웨어를 제공하지만 EPEL이 아닌 타사 소프트웨어 소스에 의존하기 때문에 패키지 충돌이 발생할 수 있습니다. 따라서 이 소스를 주의해서 사용하세요.

간단한 요약:

EPEL 소스, Nux Dextop, ELRepo 소스 및 기타 소규모 타사 소스를 시스템에 추가하세요. 소스에서 설치할 수 있으면 소스에서 설치하세요. rpm 패키지를 찾을 수 없다면, linuxbrew가 수동으로 컴파일할 수 있다면, 수동으로 컴파일하지 마세요