서버에 설치 한 대부분의 "소프트웨어"는 최신 릴리스 (Java, Tomcat, MySQL-Cluster) 여야합니다. 따라서 운 좋게도 사전 빌드 된 데비안 패키지 (배포판)가 있습니다. 따라서 모든 소프트웨어는 프로젝트 웹 페이지에서 다운로드하여 소스에서 빌드합니다.
내 질문은 데비안 시스템에 설치하는 올바른 방법은 무엇입니까?
내 주요 문제는 소스에서 직접 설치할 때 패키지 관리에 포함되지 않습니다 (적절한 상태). Checkinstall은 실제로 사용하도록 제안되지 않은 것으로 보이며 equiv에도 단점이 있습니다. dh_make 및 dpkg-buildpackage를 사용하여 자체 패키지를 빌드하여이를 처리하는 올바른 방법입니까?
항상 최신 버전이 필요한 경우 어떻게합니까?
답변:
최신 패키지를 원하는 것은 모든 OS에서 일반적인 문제입니다. 데비안의 릴리스주기는 최근 몇 년 동안 평균 2 년이므로이주기가 끝날 무렵에는 더 시급한 문제 일 수 있습니다. 이를 완화하는 한 가지 방법은 다음 버전이 거의 안정적인 안정된 릴리스주기의 끝을 향해 테스트로 이동하는 것입니다. 테스트에 대해보다 일반적으로 안정적이고 불안정한 것에 대해 이야기하고 있는지는 확실하지 않습니다. 그럼에도 불구하고 가장 최신 버전은 아직 패키지화되지 않았기 때문에 불안정한 경우에도 최신 버전을 사용하는 것이 문제가 될 수 있습니다. 데비안 개발자 / 패키지는 자원 봉사자이므로 지루하거나 다른 것들로 바 빠져서 패키지가 무너질 수 있습니다.
단순성과 구체성을 위해 패키지를 안정적으로 백 포트하는 것이 계획이지만 더 일반적으로 적용된다고 가정합니다. 따라서 안정적으로 존재하지 않는 최신 버전의 소프트웨어를 대략적인 순서로 원한다면 여기에 내가하는 일이 있습니다.
데비안 백 포트 에서 패키지를 찾으십시오 . 때로는 목적을 만족시키기에 충분한 최신 패키지를 찾을 수 있습니다. 그러나 이러한 패키지가 불안정하거나 실험적이거나 업스트림 버전에 비해 구식 인 경우가 종종 있습니다.
테스트, 불안정 또는 실험에서 직접 패키지를 설치하십시오. 안정적인 버전을 설치하려는 버전과 크게 다르지 않으면 작동 할 수 있습니다. 시스템이 최신 버전에서 기본 패키지를 설치 또는 업그레이드하려고 시도하면이 방법이 나쁜 방법이라는 것을 알게 될 것입니다. 불안정한 상태에서 설치하려고한다면
apt-get install packagename/unstable
시도하는 첫 번째 것입니다. apt의 버전이 안정적이면 불안정한 다른 패키지가 필요하기 때문에 종종 실패하며,이 주문 packagename은 불안정한 상태로 설치하기 에 충분할 정도로 높은 우선 순위만을 제공합니다. 이것이 무엇을 의미하는지 이해하지 못한다면, 가서을 읽으십시오 man
apt_preferences. 불안정한 종속성을 추가하여 기본 패키지를 업그레이드하지 않도록하십시오. 예를 들어 libc6 또는 X 또는 KDE 또는 Gnome 업그레이드를 시작하면 즉시 중단하십시오. 동일한 소스 패키지에서 다른 패키지를 업그레이드하려고 시도하는 경우 일반적으로 문제가되지 않습니다. 일반적으로 서로 밀접하게 연결되어 있기 때문입니다. 바이너리 패키지가 의존하는 소스 패키지를 확인하려면
apt-cache showsrc packagename
많은 것들이 GNU C 라이브러리 (libc6)에 의존하기 때문에 이것은 문제였습니다. 최근에는 API가 안정화 된 것으로 보이므로 이제 업그레이드하지 않아도되는 것이 가능해졌습니다. 패키지가 런타임 의존성을 안정적으로 만족하지만 여전히 제대로 작동하지 않으면 버그를 신고하십시오. 패키저가 버그가 아니라고 말하면 잘못된 것입니다. :-)
불안정하거나 실험적인 테스트에서 패키지를 직접 백 포트하십시오.
위에서 언급했듯이 백 포트는 하나의 옵션이지만 불안정하거나 실험적이거나 업스트림 버전에 비해 이러한 패키지가 오래되었습니다.
이것은 종종 재귀 종속성 빌드 루프 유형 일을 요구할 수 있습니다. 먼저 빌드 종속성을 가져와야합니다.
apt-get build-dep packagename
종속성 중 하나가 최근에 충분하지 않아서 실패하면 먼저 해당 종속성을 백 포트해야합니다. 이것은 통제 불능 상태가 될 수 있습니다. 나는 보통 2 단계 이상의 재귀를 다루어야한다면 포기한다. 그러나 실제 의존성이 반드시 명시된 것만 큼 엄격하지는 않습니다. 이전 버전이 작동 할 수 있습니다. 패키저는 종종 가장 오래된 빌드 (또는 실제로 런타임) 종속성의 버전을 찾으려고 시도하지 않습니다.
해당 업스트림에서 패키지의 가용성을 확인하십시오. 이상적으로는 배포 버전과 일치하지만 필요한 경우 다시 빌드 할 수도 있습니다.
테스트 / 불안정 / 실험에서 최신 패키지보다 최신 버전의 소프트웨어 패키지를 작성하십시오. 이것은 상대적으로 어려울 수 있지만 때로는 놀랍게도 가능합니다. 가장 먼저 알아 두어야 할 것은 이미 데비안에있는 패키지의 최신 버전을 패키징하려는 경우 이미 큰 이점으로 시작하고 있다는 것입니다. 즉, 기존 패키징을 사용할 수 있다는 것입니다. 그냥 해
apt-get source packagename
그리고 apt-get데비안 하위 디렉토리 위치를 포장 생활을 포함하여, 해당 소스 패키지를 다운로드합니다. 또한,이 패키징은 종종 일부 verson 제어 저장소 (git는 데비안에게 인기가있는 것 같습니다) 안에 있으며 안정적인 apt (현재 0.8.10.3 )는 호출 할 때 이것이 어디에 있는지 알려줍니다
apt-get source. 패키저는 출시 된 패키지에 해당하는 것보다 최신 버전의 패키징을 가질 수 있으므로이 점을 살펴보십시오. 예 :
$ apt-get source mercurial
Reading package lists... Done
Building dependency tree
Reading state information... Done
NOTICE: 'mercurial' packaging is maintained in the 'Svn' version control system at:
svn://svn.debian.org/python-apps/packages/mercurial/trunk
또는 간단하게 사용할 수 있습니다
apt-cache showsrc mercurial | grep Vcs
저장소를 나열합니다.
패키지가 오래되지 않은 경우 패키지를 수정
하고 적용된 패치를 새로 고쳐야하지만 일반적으로 여전히 좋은 출발점
입니다. 데비안에서 패키지 관리를 표준화하는 과정에있을 것 같다
당 이불 dpkg를 소스 3.0 (이불) 형식 즉 패치 상쾌에 도움이되도록.
필자는 pgf 의 데비안 패키지 를 어떻게 백 포트했는지에 대한 실제 예제로 결론을 내릴 것 입니다. pgf의 마지막 패키지 버전은 2008 년에 2.00이었으며, 그 이후로 2.10이 릴리스되었습니다. 최신 안정 버전의 pgf (2.10)로 업데이트 하십시오. 및 패치 pgf : 2.0 forbian packaging에 대한 패치로 후속 버그를 참조하십시오 . 결과적으로 pgf의 데비안 패키징은 매우 간단했으며, 2.10 패키징에서 한 줄만 바꿔야 작동했습니다. 나는 모든 lintian 불만을 진압 했다. 그러나 그것은 엄격하게 선택적이었다.
항상 최신 버전이 필요한 경우 어떻게합니까?
로서 이미 언급 , 사용 백 포트.
데비안 패키지의 작은 하위 집합 만 백 포트되므로 Debian Testing 을 사용하는 것이 좋습니다 . 안정성과 최신 성 사이의 균형이 잘 맞으며 롤링 배포판과 같은 의미입니다.
좀 더 대담하다면 데비안 불안정을 사용하십시오 . 상당히 안정적이라고 주장합니다. 일부는 다른 배포판의 "안정된"릴리스보다 더 안정적이라고 주장하기까지합니다. 어쨌든, 불안정은 새로운 패키지 버전이 정상적으로 도착하는 곳입니다. 그들은 보통 시험으로 이주하기 전에 시험을 허용하기 위해 약 10 일 동안 거기에 앉아 있습니다.
이 두 가지를 사용해도 최신 버전을 가지고 있지 않을 수 있습니다. 이 경우 데비안 실험을 살펴보십시오 . 일반적으로 새 패키지가 일반 아카이브에 불안정한 경우 (불안정 및 테스트)에 사용됩니다.
Experimental에 아직 충분한 소프트웨어 버전이 없다면 Ubuntu의 PPA를 살펴보십시오 . 위의 모든 아카이브에없는 것보다 최신 버전의 소프트웨어가 있습니다. 우분투는 데비안과 100 % 호환되지 않기 때문에주의해서 사용하십시오 (그러나 대부분의 경우 문제가 없어야합니다).
위의 방법으로 실패하면 언급 한대로 자체 패키지를 빌드하는 것 같습니다 .