(최신) 데비안 저장소에 매우 오래된 버전만 있는 소프트웨어를 설치하고 싶습니다(그리고 추가할 다른 저장소가 없습니다). 이렇게 하려면 소스에서 컴파일/설치해야 합니다.
이전 버전을 먼저 제거해야 합니까? 이렇게 하지 않고도 작동하지만 권장되는 절차가 무엇인지, 그렇지 않은 경우 문제가 발생하는지(그리고 어떤 절차) 알고 싶습니다.
예를 들어 종속성에 문제가 있습니까? 아니면 설치가 어떤 방식으로든 다른 설치와 적절하게 격리되어 있습니까?
답변1
소스에서 설치(사용)하는 경우 sudo make install,너설치 위치 선택을 담당합니다.
소스에서 설치한 경우 아래의 많은 패키지가 기본적으로 설치되지만 /usr/local, 소프트웨어를 빌드한 후 설치하기 전에 소스 패키지에 대한 빌드 지침을 확인하거나 평가판 설치를 실행해야 합니다(일반적으로 make -n install빌드 지침 참조). 의.
아래에 /usr/local설치하는 경우대개배포판에서 제공하는 패키지 버전을 방해해서는 안 되며 일반 사용자의 PATH 환경 변수에는 일반적으로 /usr/local/bin이전 /usr/bin및 가 포함되므로 /bin로컬로 빌드된 버전은대개패키지 버전보다 우선합니다.
따라서 설치 후에는 모든 것이 정상일 것입니다. 그러나 배포가 업그레이드되고 로컬로 빌드된 설치가 배포 패키지 설치보다 오래된 경우 나중에 문제가 될 수 있습니다. 를 사용하여 로컬로 빌드된 소프트웨어를 설치하는 경우 sudo make install소스 패키지에 해당 sudo make uninstall절차가 포함될 수도 있고 포함되지 않을 수도 있습니다. 빌드 디렉터리를 삭제하면 Makefile올바른 제거 단계가 포함될 수 있는 자동 생성 디렉터리가 사라질 수 있습니다.
따라서 를 사용하는 경우 sudo make install설치 프로세스의 출력을 기록하거나 나중에 수동으로 제거할 수 있도록 설치 단계에서 추가된 파일을 기록해 두어야 합니다. 미리 계획하세요. (문제의 시스템이 단일 목적 서버인 경우 소스에서 구축된 유일한 소프트웨어일 수 있으므로 /usr/local/계층 구조의 모든 파일은 해당 설치에 의해 생성되었을 수 있습니다. 따라서 /usr/local업그레이드한 후 모든 파일을 간단히 제거하는 것이 가능할 수도 있습니다. 주요 버전).
소스 패키지에 이 debian/rules파일이 포함되어 있다면 소스 코드에는 실제 데비안 패키지를 빌드하는 데 필요한 구성이 이미 포함되어 있는 것입니다. 이 경우 일반 소스 빌드 지침을 대신 사용할 수 dpkg-source -b있으며 결과적으로 .deb패키지 관리자를 사용하여 설치할 수 있는 하나 이상의 패키지가 생성되어야 합니다.
패키지 이름이 배포판의 해당 표준 버전과 동일하지만 로컬로 빌드된 패키지의 버전이 더 높은 경우 로컬로 빌드된 패키지가 배포판 버전을 대체하는 데 자동으로 사용됩니다. 배포판에서 제공하는 업데이트를 설치하는 것과 마찬가지로 패키지 관리자는 자동으로 이전 버전의 패키지를 제거하고 새 버전으로 교체합니다.
(빌드한 패키지에 암호화 서명을 위한 추가 단계를 수행하지 않는 한, 사용하는 패키지 관리 도구에 따라 패키지 관리자로부터 경고를 받을 수 있지만 방금 패키지를 직접 구축했으므로 이를 신뢰할 수 있습니다.)
이 경우 배포판 패키지 저장소의 소프트웨어 버전 번호가 로컬로 빌드된 패키지보다 높으면 패키지 관리자는 표준 패키지를 업그레이드할 때와 마찬가지로 자동으로 업그레이드를 제안합니다.
일반 소스 코드 빌드 지침과 데비안 관련 지침이 있습니다 dpkg-source -b. 빌드 중인 패키지가 특정 라이브러리에 의존하는 경우 해당 라이브러리의 호환 가능한 버전을 설치해야 할 뿐만 아니라 (빌드 지침에는 일반적으로 필요한 필수 라이브러리의 최소 버전이 나열됩니다) 게다가개발 키트컴파일러가 라이브러리 사용 방법을 알 수 있도록 합니다.
개발 패키지 이름은 일반적으로 -dev접미사가 추가된 해당 라이브러리 패키지 이름과 동일하지만 때로는 라이브러리 패키지 이름에 일부 개발 패키지 이름에서 생략된 버전 번호가 포함될 수 있습니다. (이 경우 이전 버전과의 호환성을 위해 여러 버전의 라이브러리가 있을 수 있지만 개발 패키지는 두 버전을 모두 포함하거나 최신 버전만 포함합니다.)
새 버전을 성공적으로 컴파일한 것 같으니 이는 귀하에게 관련이 없을 수도 있습니다... 하지만 소스에서 최신 버전의 소프트웨어를 빌드할 때 특정 라이브러리 또는 기타 라이브러리의 최신 버전이 필요할 수 있습니다. 배포 가능...이 라이브러리의 최신 버전에는 컴파일하려면 다른 라이브러리의 최신 버전이 필요합니다...등. 종속성 체인을 탐색하고 필요한 라이브러리의 로컬 버전을 빌드하는 것이 가능하지만(필요한 라이브러리 수가 너무 많지 않은 경우) 너무 멀리 가지 않는 것이 중요합니다. 하나 또는 두 개의 특수 라이브러리의 새 버전을 제공하는 것은 괜찮을 수 있지만 여러 시스템 구성 요소에서 사용되는 업그레이드된 버전의 라이브러리를 구축하기 시작하는 경우 최신 배포판으로 전환하는 것을 고려해야 합니다. 새 버전을 로컬에서 컴파일 glibc하고 시스템 전체에서 사용하기 위해 설치하는 것은 당연한 일입니다.
답변2
TL;DR 대답은 모든 것이 예상대로 작동한다면 자신이 하고 있는 일을 모르거나 위험하다고 느끼지 않는 한 "실행 중인 시스템을 건드리지 마십시오"입니다. :) 그러나 apt remove <software>사용하는 것이 상대적으로 안전하며(또는 유사) 버전 충돌 또는 매우 이 경로를 통해 깨지는 종속성이 거의 없습니다(apt를 통해 설치된 소프트웨어의 경우).
첫 번째 단계로 소프트웨어의 종속성을 수동으로 확인할 수 있습니다.
ldd --verbose <program>
그러나 이것은 빠르게 복잡해질 수 있습니다. 제가 조언하는 것은 오래된 소프트웨어에서 라이브러리가 설치되었다는 이유만으로 맹목적으로 라이브러리를 제거하지 말라는 것입니다. 다른 프로그램에서도 사용할 수 있습니다.
다양한 버전의 라이브러리는 일반적으로 적절한 명명 규칙을 통해 잘 "격리"됩니다. 불행하게도 손상된 공유 라이브러리를 설치하면 항상 문제가 발생합니다. 이 경우 라이브러리를 다시 설치하거나 소프트웨어에 전적으로 의존해야 합니다. 어떤 소프트웨어를 먼저 설치할지 신중하게 고려하여 후속 문제를 완화할 수 있습니다(가상 시스템의 미러를 설정하고 거기서 테스트할 수도 있음).
물론 위의 내용은 공유된 파일에만 적용됩니다. /home/에 설치된 파일과 디렉토리는 비교적 안전하게 삭제할 수 있습니다. Gem, Shard 또는 Python 패키지와 같은 항목에는 예외가 있을 수 있지만 비교적 쉽게 다시 설치할 수 있습니다. 또한, 액세스 키나 잠금 해제 코드를 생성한 경우 삭제하기 전에 백업을 만드세요.
물론, 이 주제에 대한 대답은 "그냥 해라"부터 "절대로 건들지 마"까지 다양할 수 있고, 이 주제를 둘러싸고 확실히 많은 의견이 있습니다.
도움이 되길 바랍니다.
답변3
/usr/localLinux에서는 소스에서 소스 간에 새 소프트웨어를 설치하는 것이 표준 관행입니다 . /opt즉, 설치된 소프트웨어를 제거할 필요가 없습니다.