(이 답변에 대한 질문 / 의견이 있으면 의견을 추가하십시오. 또는 충분한 답변이 있으면 채팅에 핑 (Ping) 할 수 있습니다.)

새로운 버전의 데비안에서 바이너리 꾸러미를 직접 설치하기 – 답이 아닙니다.

데비안 기반 배포판의 일부 버전을 실행한다고 가정합니다. 사용 가능한 것보다 최신 버전의 패키지를 원합니다. 모든 초보자가 먼저 Debian 버전에 바이너리 패키지를 직접 설치하려고 시도합니다. 실행중인 버전 및 패키지의 최신 버전에 따라 작동하지 않을 수 있습니다. 일반적으로이 절차는 제대로 작동하지 않습니다.

예를 들어 안정에서 직접 테스트 / 불안정에서 바이너리 패키지를 설치하려고하는 경우를 고려하십시오. 테스트 / 불안정이 그 순간 안정에 거의 도달하지 않는 한 이것은 잘 진행되지 않을 것입니다. 그 이유는 데비안과 같은 Linux 기반 바이너리 배포판의 특성과 관련이 있습니다. 이러한 운영 체제는 공유 라이브러리에 크게 의존하며 이러한 종속성은 버전에 따라 매우 밀접한 관계가 있습니다. 종종 필요 이상으로 훨씬 더. 데비안은 현재 버전 의존성을 “긴밀하게”만드는 좋은 방법을 가지고 있지 않다. 즉 버전 의존성이 필요한만큼 정확하게 제한적이라고 말하는 짧은 방법이다.

이것은 사용자에게 무엇을 의미합니까? 예를 들어 slrn데비안 불안정에서 데비안 안정으로 say를 설치한다고 가정 해보십시오 . 이것은 어떻게 생겼습니까?

# apt-get install slrn/unstable
Reading package lists... Done
Building dependency tree
Reading state information... Done
Selected version '1.0.1-10' (Debian:testing [amd64]) for 'slrn'
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 slrn : Depends: libc6 (>= 2.15) but 2.13-38+deb7u1 is to be installed
E: Unable to correct problems, you have held broken packages.

에서 발생한 오류에도 불구하고 apt여기에 깨진 패키지가 없습니다. 그래서 무엇이 잘못 되었습니까? 문제는 libc6unstable slrn이 컴파일 된 버전이 Debian 스 테이블에서 사용 가능한 버전과 다르고 버전 번호가 높다는 것입니다. ( libc6GNU C 라이브러리입니다. C 라이브러리는 모든 유닉스 계열 운영 체제의 중심이며 GNU C 라이브러리는 Linux 기반 운영 체제가 일반적으로 사용하는 버전입니다.)

따라서 불안정한 slrn버전은 libc6안정적인 버전 보다 높은 버전의 버전이 필요합니다 . 패키지가 상위 버전의 라이브러리에 대해 컴파일되었으므로 반드시 해당 라이브러리의 상위 버전이 필요하지는 않지만 종종 그런 경우가 있습니다.

문법

apt-get install slrn/unstable

의미 : 불안정을 사용 slrn하지만 다른 모든 패키지의 경우 안정 버전 만 사용하십시오. 보다 정확하게는 우선 순위 번호를 사용합니다. 자세한 내용 man apt_preferences을 참조하십시오.

하나는 할 수 있습니다

apt-get install -t unstable slrn

이것은 훨씬 더 효과가 있지만 일반적으로 원하지 않습니다. 왜?

즉 , 패키지가 안정된 상태에서 모든 패키지를 불안정한 상태로 임시적으로 처리 합니다 . 따라서 이것은 slrn버전 번호가 높은 불안정한 의존성을 불안정하게 가져오고 일반적으로 적용됩니다. 여기에는 일반적으로 이미 설명한 이유로 GNU C 라이브러리가 포함됩니다. 이제, 이러한 접근 방식은 일반적으로 “종속성”입니다. 종속성은 정의에 의해 만족 될 것입니다 (불안정한 것에 slrn는 불안정한 것으로 만족되는 종속성이 있음 ). 그러나 갑자기 라이브러리 버전으로 강제 실행되는 패키지의 혼합으로 끝납니다. 그들이 만든 것과 다릅니다. 이것은 아마도 잘 끝나지 않을 것입니다.

대답은 … 백 포트입니다!

그렇다면 올바른 방법은 무엇입니까? 일반적으로 “백 포트”로 알려진 최신 버전의 데비안 소스를 다시 빌드하는 것입니다. 다음과 같은 경우를 고려하십시오.

해당 버전의 데비안에서 사용 가능한 추가 패키지의 반 공식 / 공식 소스가 있습니다.

보기의 첫 번째 장소입니다 데비안 백 포트 데비안 백 포트의 공식 사이트입니다.

구체적인 예를 들면 다음과 같습니다.

릴리스에 적합한 백 포트 라인을 추가하고 새 패키지를 찾은 다음 백 포트에서 무언가를 명시 적으로 설치하십시오 (백 포트가 기본적으로 비활성화되어 있기 때문에).

echo "deb http://ftp.debian.org/debian stretch-backports main" | sudo tee /etc/apt/sources.list.d/stretch-backports.list
sudo apt-get update
sudo apt-get install -t stretch-backports git

이것은 스트레치에 포함 된 안정적인 것보다 유용한 새로운 기능을 가진 최신 안정 버전의 git을 얻습니다 (예 : ‘include’를 사용하면 여러 구성 파일을 결합하거나 ~ / work / projects / vs ~ / personal /에 대한 사용자 이름을 변경할 수 있습니다 프로젝트 /).

살펴볼 또 다른 곳은 우분투 관리자의 다양한 PPA입니다. “packagename PPA”를 검색 할 수 있습니다.

해당 버전의 OS에서 사용할 수있는 최신 버전의 패키지는 없지만 최신 버전 / OS에서 사용할 수있는 최신 버전이 있습니다. 백 포트의 표준 사례입니다.

백 포트는 실행중인 버전에서 이후 버전의 데비안에서 데비안 소스를 다시 빌드한다는 것을 의미합니다. 이 절차는 패키지에 따라 쉽고 복잡 할 수 있습니다. 이 작업을 수행하는 방법에 대한 개요는 다음과 같습니다.

초보자를위한 간단한 백 포트 자습서

구체적으로 현재 데비안 마구간을 실행하고 있다고 가정합니다. 패키지 slrn를 예로 사용하겠습니다 .

먼저 모든 데비안 패키징 파일 debian/은 소스 디렉토리 의 하위 디렉토리에 있습니다.

첫 번째 단계는 최신 버전이 있는지 확인하는 것입니다. 를 사용하여이 작업을 수행 할 수 있습니다 apt-cache policy.

apt-cache policy slrn

slrn:
  Installed: 1.0.0~pre18-1.3
  Candidate: 1.0.0~pre18-1.3
  Version table:
     1.0.1-10 0
         50 http://debian.lcs.mit.edu/debian/ testing/main amd64 Packages
         50 http://debian.lcs.mit.edu/debian/ unstable/main amd64 Packages
 *** 1.0.0~pre18-1.3 0
        500 http://debian.lcs.mit.edu/debian/ wheezy/main amd64 Packages
        100 /var/lib/dpkg/status
     1.0.0~pre18-1.1 0
        500 http://debian.lcs.mit.edu/debian/ squeeze/main amd64 Packages

우리는 백 포트하고 싶습니다 1.0.1-10.

1 단계:

주의 : deb-src다운로드하려는 소스 버전 의 라인이에 표시되어 있는지 확인하십시오 /etc/apt/sources.list. 예를 들어 불안정 버전의을 (를) 다운로드하려면 불안정한 줄 slrn이 필요 deb-src하거나 작동하지 않습니다. deb소스를 다운로드하기 위해 해당 라인이 필요하지는 않지만 apt-cache policy해당 정보를 사용하므로 해당 deb라인 apt-cache policy이없는 경우 관련 버전이 표시되지 않습니다. 당신이이있는 경우 deb라인을 엔트리에서 사용하는 최신 버전 핀 것을 잊지 마세요 /etc/apt/preferences또는 이와 유사한합니다. 의 항목 /etc/apt/preferences(불안정에 대한)이 같은 예를 들어, 작동합니다.

Package: *
Pin: release a=unstable
Pin-Priority: 50

에 줄을 추가하면 나중에 /etc/apt/sources.list실행하는 것을 잊지 마십시오 apt-get update.

의 소스를 다운로드하십시오 slrn. 좋은 곳은 /usr/local/src/slrn입니다.

apt-get source slrn=1.0.1-10

2 단계:

백 포트를 업스트림 버전과 구별 할 수 있도록 버전 번호를 약간 변경하십시오. Run을 실행 dch -i하면 debian/changelog파일에 항목이 자동으로 추가 됩니다. 그런 다음 예를 들어 항목을 다음과 같이 변경하십시오.

slrn (1.0.1-10.username) UNRELEASED; urgency=low

  * Backport to wheezy.

 -- User <user@domain>  Sun, 02 Feb 2014 23:54:13 +0530

3 단계 :

소스를 구축하려고 시도하십시오. 빌드에 필요한 패키지를 사용할 수 없으면 시도가 실패합니다. 디렉토리를 소스 디렉토리로 변경하십시오. 패키지 debuild에서 사용하십시오 devtools.

cd slrn-1.0.1/
debuild -uc -us

빌드 종속성이 충족되면 소스는 소스 디렉토리 위의 레벨에서 일부 뎁을 빌드하고 생성합니다. 이 경우 /usr/local/src/slrn.

4 단계 :

빌드 종속성이 충족되지 않았다고 가정하십시오. 그런 다음 빌드 종속성을 설치해야합니다. 버전에 따라 종속성을 사용할 수 없거나 사용 가능한 경우 올바른 버전에서 사용하지 못할 수 있으므로이 기능이 작동하거나 작동하지 않을 수 있습니다.

NB : 불행히도 데비안 패키지가 필요한 것보다 높은 빌드 종속성 버전을 요구하는 것은 드문 일이 아닙니다. 데비안에서는이를 확인하는 자동화 된 방법이 없으며, 종종 패키지 관리자는 해당 버전 / 릴리스에서 작동하는 한 신경 쓰지 않습니다. 따라서 의존성 버전에 회의적인 태도를 취하고 상식을 사용하십시오. 예를 들어, Python 및 GNU 도구와 같이 널리 사용되는 패키지는 데비안 패키지 프로그램의 목록에 상관없이 특정 버전의 종속성에 의존하지 않습니다.

어쨌든 설치를 시도 할 수 있습니다

apt-get build-dep slrn=1.0.1-10

이것이 성공하면 패키지를 다시 빌드하십시오 (STEP 2). 실패하면 추가 작업이 필요합니다. 파일 debuild에서 빌드 종속성 을 살펴보고 debian/control필요한 경우이를 변경할 수 있습니다. 이제 그것에 대해 이야기하겠습니다. 다음은 slrn에 대한 빌드 종속성입니다.

Build-Depends: debhelper (>=9), libslang2-dev, libuu-dev,
 exim4 | mail-transport-agent, libgnutls-openssl-dev, po-debconf, autoconf,
 libcanlock2-dev, autotools-dev, dpkg-dev (>= 1.16.0), chrpath, dh-autoreconf, inn2-inews

사용의 대안 apt-get build-dep은 다음을 수행하여 수동으로 설치하는 것입니다.

apt-get install debhelper libslang2-dev ...

제어 파일에서이 값을 변경하기 시작 apt-get build-dep하면 더 이상 올바른 작업을 수행하지 않으므로 수동 설치로 전환해야합니다 .

사용 가능한 최신 버전의 소프트웨어 패키지 버전이 없습니다. 사용 가능한 옵션은 최신 버전을 패키지하는 것입니다.

대부분의 경우 새로운 소스와 함께 이전 버전의 소프트웨어에서 패키징을 재사용 할 수 있습니다. 이 접근법은 문제를 일으킬 수 있습니다. 특히 이전 버전의 소프트웨어에 적용된 패치는 여기에 적용되지 않을 수 있으므로 소스와 다시 동기화해야 할 수도 있습니다. 현재 표준이되고있는 3.0 (퀼트) 소스 형식은 퀼트를 사용하며 패치는 debian/patches디렉토리에 있습니다.

그러나 이러한 문제에 대한 자세한 설명은이 게시물에서 다루지 않습니다.

---

답변