설치된 애플리케이션에 대한 소스 컴파일의 영향

.deb공식 리포지토리 제공 여부에 관계없이 대부분의 패키지는 접두사로 설치됩니다 /usr.

이는 사용자가 실행하는 실행 파일이 들어가 /usr/bin거나 /usr/sbin(또는 /usr/games게임인 경우) 공유 라이브러리가 들어가고 /usr/lib, 플랫폼 독립적인 공유 데이터가 들어가고 /usr/share, 헤더 파일이 들어가고 /usr/include, 자동 설치된 소스 코드가 들어가는 것을 의미합니다 /usr/src.

작은 패키지 세트가 /접두어로 사용됩니다. 예를 들어 bash패키지 bash는 . 특정 유형의 네트워크 공유... 만일의 경우를 대비해 원격 파일 시스템)./bin/usr/bin/usr

.deb주로 다음을 사용하여 생성된 소규모 패키지 모음입니다 .빠르게, 내부에 패키지별 폴더를 만들고 /opt모든 파일을 여기에 넣습니다. 그 외에도 대부분의 경우 /opt시스템의 패키지 관리자를 사용하지 않지만 소스에서 컴파일하지 않는 실행 가능한 설치 프로그램에서 설치된 소프트웨어에 의해 위치가 사용됩니다. (예를 들어 MATLAB과 같은 독점 프로그램을 설치하는 경우 /opt.

이 모든 것과 반대로, 소스 아카이브를 다운로드할 때(또는 Bazaar 또는 git과 같은 개정 제어 시스템에서 소스 코드를 가져올 때) 이를 빌드하고 설치합니다.대개/usr/local별도로 지정하지 않는 한 접두사에 설치합니다 . 이는 실행 파일이 /usr/local/bin, /usr/local/lib또는 에 있고 /usr/local/games라이브러리가 등에 있음을 의미합니다 /usr/local/lib.

몇 가지 예외가 있습니다. 일부 프로그램은 기본적으로 접두사에 설치되므로 /usr패키지에 있는 동일한 프로그램의 설치를 덮어씁니다. .deb일반적 으로 이를 빌드하는 ./configure --prefix=/usr/local대신 실행하여 ./configure이를 방지 할 수 있습니다. 다시 한 번 강조하지만, 대개는 이것이 필요하지 않습니다.

(이러한 이유로 구축하고 설치하는 소스 코드를 시스템 전반에 걸쳐 사용하는 것이 완벽합니다 /usr/local/src. 이는 이러한 목적을 위해 존재합니다.)

패키지 버전이 설치되어 /usr있고 소스에서 설치한 버전이 다음 위치에 있다고 가정합니다 /usr/local.

• 설치된 패키지의 파일은 덮어쓰지 않습니다.

  일반적으로 명령줄에서 프로그램을 수동으로 호출하면 최신 버전이 실행됩니다( /usr/local/bin실행 파일이 설치된 위치가 PATH환경 변수에 있고 해당 /usr접두사가 붙은 디렉터리 앞에 나타나는 경우 /usr/bin).

  하지만 메뉴나 검색을 통해 생성되고 접근되는 런처에는 몇 가지 문제가 있을 수 있습니다. 또한 여러 버전의 라이브러리가 서로 다른 위치에 설치되어 있는 경우 어떤 소프트웨어가 어떤 버전을 사용할지 결정하는 것이 약간 복잡해질 수 있습니다.

  당신이 실제로 그렇지 않다면사용두 가지 버전의 프로그램 또는 라이브러리가 있는 경우 일반적으로 사용되지 않는 버전을 제거해야 하지만 제한된 경우에는 종속성을 충족하기 위해 설치된 패키지를 유지해야 할 수도 있습니다.

그러나 어떤 이유로든 파일을 덮어쓴 경우(예: 소스 코드가 /usr대신 설치된 경우 /usr/local):

• 패키지 관리자는 자신이 설치하는 소프트웨어가 어떻게 변경되었는지 알 수 없습니다. 이전 버전이 설치되어 있다고 생각합니다. 나쁜 문제를 일으킬 수 있습니다. 이런 상황을 피해야 합니다. 이러한 상황이 발생하면 sudo make uninstall원본(일반적으로 디렉터리에 있음)에서 설치한 소프트웨어를 제거한 다음 덮어쓴 파일을 제공하는 패키지를 제거해야 합니다./usr/local/src/program-or-library-name아니요소스에서 설치된 버전을 제거하여 복원합니다. 그런 다음 원하는 버전을 다시 설치하십시오.

종속성을 만족시키는 경우:

• .deb패키지가 소스에서 설치한 소프트웨어에 의존하고 소스에서 설치한 버전(또는 그 이상)이 필요한 경우 패키지는아니요성공적으로 설치되었습니다. (또는 더 정확하게는 "설치"할 수는 있지만 "구성"되지 않으므로 사용할 수 없습니다.) 종속성은 실제로 사용자가 아닌 설치된 패키지 버전에 따라 해결됩니다. 그것을 해결하는 소프트웨어가 있습니다.

  마찬가지로, 설치 중인 소프트웨어가 의존하는 패키지에서 제공하는 파일을 수동으로 제거하더라도 소프트웨어는 최소한 완전히 설치를 시도합니다. (일반적으로 어떤 목적으로든 이를 악용하려고 시도해서는 안 됩니다. 오류 메시지를 기반으로 작동하는 패키지 관리자는 거의 항상 나쁜 것입니다.)

따라서 원하는 소프트웨어 버전을 제공하는 패키지를 찾을 수 없는 경우 .deb컴파일된 소프트웨어에서 고유한 패키지를 생성하고 해당 패키지에서 설치해야 할 수도 있습니다. 그러면 패키지 관리자는 무슨 일이 일어났는지 알게 될 것입니다. 실제로 다른 사람의 컴퓨터에서 제대로 작동할 필요가 없는 자신만의 사용을 위한 패키지를 만드는 것은 그리 어렵지 않습니다. (그러나 현재의 표현 방식을 고려할 때 이것이 귀하의 질문 범위를 벗어날 수도 있다고 생각합니다.)

소프트웨어 센터에서 설치하거나 APT 명령( apt-get, aptitude)을 사용하여 설치하는 내용은 dpkg패키지 관리 시스템에 알려져 있습니다. 낮은 수준의 패키지 조작 도구인 APT 및 유사한 도구는 실제 설치를 수행하고 종속성 및 패키지 다운로드를 처리하기 위해 dpkg호출하는 높은 수준의 도구입니다 .dpkg

소스에서 프로그램을 컴파일하면 패키지 관리자가 이를 인식하지 못합니다. 상황을 추적하고 설치를 덮어쓰기가 더 어렵기 때문에 따라야 하는 Linux의 규칙은 다음과 같습니다.

• /bin, /lib, /sbin는 /usr패키지 관리자용으로 예약되어 있습니다.
• 하지만 이는 /usr/local시스템 관리자를 위한 것입니다. 디렉터리 계층 구조를 존중하되 파일을 직접 관리해야 합니다.

바라보다Ubuntu 10.04에서 vim/gvim을 7.3으로 업그레이드하는 가장 좋은 방법은 무엇입니까?최신 버전의 소프트웨어를 다운로드할 수 있는 방법 목록을 확인하세요. 가장 쉬운 방법은암페타민,그렇다면. 바이너리 패키지를 얻거나 소스에서 컴파일하는 경우 다음을 사용하는 것이 좋습니다.가게수동으로 설치된 소프트웨어를 관리합니다. 또는,나만의 .deb가방 만들기— 더 많은 작업이 필요하지만 자주 업그레이드하거나(다음 마이너 버전에 대한 패키지 재작업은 일반적으로 매우 빠릅니다) 동일한 배포를 실행하는 많은 시스템에 배포하는 경우 그만한 가치가 있습니다.

대부분의 프로그램과 마찬가지로 를 실행하면 ./configure && make && sudo make install해당 프로그램이 에 설치됩니다 /usr/local. 소스 코드(일반적으로 README또는 이름의 파일 INSTALL)와 함께 제공된 설명서를 확인하거나 실행하여 ./configure --help이러한 경우인지 확인하십시오. 프로그램이 아래에 설치되면 /usr/local패키지 관리자에서 제공하는 버전을 방해하지 않습니다. /usr/local/bin시스템의 첫 번째 줄입니다 PATH. 관리자(루트)로 실행 해야 합니다 make install. 루트로 컴파일하지 마십시오. 위에서 언급했듯이 /usr/local.

포장 및 기타 여러 요인에 따라 다릅니다.

1. 사용된 명명 규칙 - 바이너리의 파일 이름에 버전 번호가 포함되어 있는지 여부
2. 설치 위치 - 기본값은 opt이지만 패키지 버전은 /usr에 있습니다.
3. 더 많은 가능성

간단히 말해서:
보편적인 대답은 없습니다. 패키지에 대한 의존도가 높습니다. 가능하다면 소스에서 컴파일하는 대신 공식 +1 PPA를 사용해야 합니다.