소스에서 설치된 소프트웨어를 업그레이드하는 방법은 무엇입니까?

우분투 저장소의 패키지가 상당히 오래되었으므로 소스에서 NGinx를 설치합니다. 이러한 유형의 설치를 업그레이드하는 가장 좋은 방법이 무엇인지 궁금합니다.

현재 진행중인 워크 플로입니다.

• 새로운 소스 다운로드
• 동일한 경로로 소프트웨어를 설치하십시오.
• 소프트웨어를 다시 시작합니다.

이것이 최선의 길이 아니라고 말해줍니다.

제안?

이것이 최선의 방법이 아니라고 생각할 권리가 있습니다. 이 경로에는 많은 수동 단계가 필요하며 오류가 발생하기 쉬우 며 확장이 잘되지 않습니다.

리눅스 배포판으로 작업 할 때는 가능한 한 패키지 관리에 충실해야합니다.

패키지 관리 사용의 장점 :

• 의존성 지원
• 쉬운 설치 / 제거
• 소프트웨어 인벤토리
• 구성 파일 처리를 포함한 업그레이드 / 다운 그레이드 지원
• 소스 패키지는 기본적으로 빌드 프로세스를 문서화하고 작성되면 자동화합니다.
• 패키지 서명
• 그리고 더.

소스에서만 작업을 시작하면 이러한 모든 훌륭한 기능을 잃어 버리고 일이 매우 복잡해지기 시작합니다.

특이한 문제를 해결하려면, 우분투 백 포트 저장소를 확인하십시오 . 아마도 사용 가능한 NGinx 버전이 업데이트되어있을 것입니다.

그들이 적합한 버전이 없다면, 가장 좋은 해결책은 백 포트 우분투 패키지를 직접 만드는 것입니다. 실제로 그렇게 어렵지는 않으며 매번 소스에서 수동으로 컴파일하는 것보다 작업이 적습니다. 백 포팅은 기본적으로 우분투에서 소스 패키지를 가져 와서 이전 upsteam tar.gz 파일을 원하는 최신 파일로 바꾸고 패키지를 다시 빌드해야합니다.

이 안내서 를 사용 하여 패키지를 백 포트 할 수 있습니다 .

별도의 위치에 다른 버전을 설치하고 사용하려는 버전으로 symlink를 연결하는 것이 매우 편리하다는 것을 알았습니다.

lrwxr-xr-x  1 root  wheel     7B Jun  7 18:26 /usr/local/foo -> foo-1.0
drwxr-xr-x  2 root  wheel   512B Jun  7 18:26 /usr/local/foo-1.0
drwxr-xr-x  2 root  wheel   512B Jun  7 18:26 /usr/local/foo-1.1

이점은 다음과 같습니다.

• 업그레이드 중 서비스 중단 시간 최소화
• 쉬운 롤백
• 여전히 같은 o '경로를 사용할 수 있습니다. /usr/local/foo/bin/bar

물론 이전 버전의 구성 변경 사항을 다시 적용해야하지만 일부 버전 관리 시스템 (RCS / SVN / GIT) 또는 Bcfg2 와 같은 구성 관리 도구를 사용할 수 있습니다 .

그리고 물론 이것은 소수의 호스트에만 적합합니다.

다음에 ... * .rpm 또는 * .deb로 컴파일하는 것은 어떻습니까?

이것을 단일 머신에 설치하려는 경우, 매번 소스에서 수행하는 것이 가장 좋은 방법입니다. 이것을 여러 머신에 설치하고 일관성을 유지하려면 데비안 패키지를 만드는 방법을 배우는 것이 좋습니다. 우분투에서 패키징을 기본으로 사용할 수 있습니다.

좋은 방법이 없습니다. 효과적인 패키지 관리가 만들어진 이유는 바로이 문제를 해결하기위한 것입니다. 소스 컴파일 된 것들을 업그레이드하고 제거하는 것은 어렵습니다.

나는 Tom과 David에 동의합니다.

이것이 일회성 사례라면 소스에서 다시 컴파일하는 것이 가장 좋습니다. 여러 시스템에있는 경우 지원되는 패키지 관리로 이동해야합니다.

이것이 유일한 방법이라는 것이 두렵습니다. 유지할 서버가 더 많은 경우 컴파일 할 결과를 컴파일하고 패키지 할 수있는 별도의 테스트 환경을 갖는 것이 좋습니다.

이렇게하면 설정이 약간 표준화되고 많은 서버에 쉽게 배포 할 수 있습니다. 또한 프로덕션 머신에는 gcc가 필요하지 않습니다 [많은 사람들이 보안상의 이점으로 고려할 것].