소스에서 빌드하는 것과 설치 패키지를 사용하는 것의 차이점은 무엇입니까?

모든 소프트웨어는프로그램, 또한 ~으로 알려진소스코드 패키지. 따라서 모든 소스 코드 패키지에는세워짐먼저 시스템에서 실행하십시오.

이것바이너리 패키지지어진 것이에요원천많은 사용자가 설치하고 사용할 수 있도록 전담 인력이 소프트웨어에 공통 기능과 매개변수를 제공합니다.

바이너리 패키지는설치가 용이함.
하지만모든 옵션을 사용하지 못할 수도 있습니다.업스트림 패키지에서.

따라서 소스에서 설치하려면 소스를 직접 빌드해야 합니다. 이는 종속성을 직접 처리해야 함을 의미합니다. 또한 패키지를 적절하게 빌드하려면 패키지의 모든 기능을 알아야 합니다.

소스에서 설치의 장점:

• 보안 패치든 새로운 기능이든 최신 버전을 설치하고 항상 최신 상태를 유지할 수 있습니다.
• 필요에 맞게 설치 시 기능을 축소할 수 있습니다.
• 마찬가지로 바이너리에서는 사용할 수 없는 일부 기능을 추가할 수 있습니다.
• 원하는 위치에 설치하세요.
• 일부 소프트웨어의 경우 올바른 설치를 위해 하드웨어별 정보를 제공할 수 있습니다.

간단히 말해서 설치원천당신을 위한헤비 커스터마이징옵션을 설치하는 동안 많은 노력이 필요합니다바이너리더 쉽지만 할 수 있습니다맞춤설정할 수 없습니다.당신이 원하는대로.

고쳐 쓰다:아래 댓글에 보안 관련 매개변수를 추가하세요. 예, 바이너리에서 설치할 때 소스 코드의 무결성이 없다는 것은 사실입니다. 그러나 바이너리를 어디서 구하느냐에 따라 다릅니다. 새로운 프로젝트에 대한 바이너리를 얻을 수 있는 신뢰할 수 있는 소스가 많이 있지만 유일한 단점은시간. 업데이트된 바이너리나 새 프로젝트가 신뢰할 수 있는 저장소에 표시되는 데 시간이 걸릴 수 있습니다.

가장 중요한 것은 소프트웨어 보안에 관한 이 재미있는 점을 강조하고 싶다는 것입니다.벨 연구소 페이지제공:조아래 댓글에.

소스 파일에는 개발자가 선택한 언어(C, C++, Python 등)로 작성한 원본 코드가 포함되어 있으며 보편적입니다. 이는 배포판에만 국한되지 않으며 대부분의 경우 운영 체제에만 국한되지 않습니다.

패키지(예: RPM 또는 DEB)는 특정 배포용으로 준비된 바이너리 실행 파일(또는 해석된 스크립트 등)입니다. 컴파일을 위한 소스 준비(필요한 패치 추가 등), 실제 컴파일, 배포판별 구성 파일 생성, 사전 및 사후 설치 스크립트 생성 등의 작업은 모두 패키지 관리자가 수행합니다.

즉, 소스에서 설치하기로 선택한 경우 직접 수행해야 하는 모든 노력이 패키지에 완료되었습니다.

다음과 같은 이유로 거의 모든 상황에서 패키지를 사용하는 것이 더 쉽습니다.

• 설치가 더 쉽습니다.
• 배포판과 함께 작동하도록 특별히 설계되었습니다.
• 때때로 패키지 관리자는 배포판 관련 버그를 수정하기 위해 패치를 적용합니다.
• 패키지 관리자가 해당 패키지를 제거합니다.
• 패키지 관리자가 모든 종속성을 관리합니다.
• 패키지 관리자가 업데이트를 담당합니다.
• 시스템에 개발 도구(컴파일러, make 등)를 설치할 필요가 없습니다.

그러나 때로는 패키지 버전이 이전 버전이거나 심지어 패키지 버전이 없는 경우도 있습니다. 이 경우 유일한 옵션은 직접 컴파일하는 것입니다. 이렇게 하려면 다음 사항을 고려해야 합니다.

• 시스템에 모든 개발자 도구가 설치되어 있어야 합니다.
• 업데이트 확인 및 재컴파일은 귀하의 책임입니다.
• 패키지를 포함하여 모든 종속성이 설치되어 있는지 확인해야 합니다. 패키지 dev가 많을 수 있습니다.
• 배포판에서 예상대로 작동하지 않으면 문제를 디버깅해야 할 수도 있습니다.

추가 노력을 기울일 의향이 있는 경우 소스에서 컴파일하면 다음과 같은 이점을 얻을 수 있습니다.

• 사용 가능한 최신 버전에 액세스
• 성능/안정성을 향상시키기 위해 컴파일 프로세스를 최적화하는 옵션
• 즐기다!

일부 배포판의 사전 빌드된 패키지는 설치 및 실행할 수 있는 바이너리 실행 파일(예: RPM 및 DEB)을 제공하는 반면, 다른 배포판은 단순히 컴파일 프로세스를 자동화하는 패키지를 제공합니다.

젠투가 ebuilds그 예입니다. 패키지는 기본적으로 실행 파일을 컴파일하고 설치하는 방법을 설명하는 패키지 관리자에게 보내는 지침입니다. 이는 기존 패키지 관리자(자동 업데이트, 제거 등)의 많은 장점을 갖고 있으면서도 사용자가 원하는 대로 컴파일 프로세스를 최적화할 수 있습니다.

Arch Linux에는 주류 패키지가 바이너리이고 많은 추가 패키지가 파일을 사용하여 시스템에서 컴파일되는 패키징 시스템이 있습니다 PKGBUILD.

다른 답변 외에도 다음을 추가하고 싶습니다.

프로그램을 직접 컴파일하기로 결정했다면 컴파일이 한 번만 수행하는 작업이 아니라는 점을 고려해야 합니다. 컴파일하기로 결정한 애플리케이션의 개발 메일링 리스트를 구독하고 새 릴리스, 특히 보안 업데이트에 대한 정보를 계속 받아볼 수 있습니다.

애플리케이션을 업데이트할 때마다 새 버전을 다시 컴파일해야 하므로 매주 시간을 내야 한다는 점을 기억하세요.

감당할 수 없다면 패키지 관리자에게 작업을 맡기는 것이 더 좋습니다.

두 가지 접근 방식(최신 소프트웨어, 간단한 설치/제거, 대부분의 배포판 조정 및 조정 포함, 로컬 요구 사항에 맞게 최적화 가능)과 비용(최신 상태 유지, 버그 주의) 및 최종 패치의 장점 개발 후에는 배포판의 소스 패키지부터 시작하여 자신만의 패키지를 빌드하여 완화할 수 없는 버그 수정 및 버전 간 비호환성을 스스로 해결해야 합니다. 즉, 배포판에서 소스 코드 패키지의 압축을 풀고, 소스 코드를 업스트림 버전으로 교체하고, 배포판의 패치나 구성 조정이 여전히 적용되는지 확인하고, 바이너리 패키지를 빌드합니다(패키지된 콘텐츠의 버전을 변경해야 합니다! ) 그것을 설치하십시오. 예, 단순히 구축하고 설치하는 것 이상입니다.