debian의distributions

3845 단어

debian의distributions(by hanlray(at) gmail.com)


code name

debian archive에서 진정한 distribution 디렉터리는 code name, 예를 들어 sarge, etch를 사용하고 다른 이름의 distribution 디렉터리, 예를 들어 stable/testing/unstable, debian 3.1 등은 코드name 디렉터리를 가리키는 기호 연결이다.코드name을 사용하면 디스커버리를 일치하게 지정할 수 있으며, 디스커버리 release의 상태와 상관없이, 예를 들어 현재 테스트에 있는 etch 디스커버리언은release 후에도 etch로 인용할 수 있습니다.
sid는 특수한 코드name입니다. distribution은 항상 unstable 상태에 있고,release는 영원히 없습니다.

release

testing은 release를 위한 다음 코드 name (코드 name이라는 distribution) 을 가리킨다.매일 브리티니라는scripts가 실행되고sid에서 일정한 조건을 충족시키는 packges를 선택하여 테스트링에 업데이트됩니다.release 관리자가 적당하다고 느낄 때 테스트링은frozen에 의해 제어됩니다. 이것은 패키지가 unstable에서 테스트링까지 제어하는 정책이 빡빡해지고 too buggy의 패키지가 제거되며 버그fixes를 제외한 다른 변경 사항은testing에 들어갈 수 없습니다.진도에 따라 시간이 지나면 테스트링은frozen에 의해 더욱 진일보된다.테스트 처리 세부 사항은 debian-devel-announce에서 릴리즈 팀에 발표됩니다.Release Team이 현재 문제의 해결 상황에 만족할 정도에 이르렀을 때testing은release:testing이stable로 개명되었다. 그래서stable는 새로운release의codename를 가리키며 새 복사본이 생성되었다. 다음release의codename로 명명되고 새로운testing이 되었다. 이전의stable는oldstable로 개명되었다.따라서released에 대응하는 코드name의 버전 번호(예를 들어sarge는 3.1,etch는 4.0)가 발표되었습니다.
설령 stable distribution이 불가피하게 bugs가 존재한다 하더라도 이러한 bugs를 해결하는 업데이트 패키지는 debian archive의 stable-proposed-updates 디렉터리에 먼저 업로드되어 더욱 진일보한 테스트를 한다. Release Team은 이러한 업데이트가 stable에 포함될 수 있는지를 정기적으로 평가하고 결정한다. 업데이트가 stable로 옮겨진 후에 stable distribution의 Revision level이 점차 증가한다.예를 들어 3.0에서 3.0r1, 2.2r4에서 2.2r5로 변경

APT::Default-release

서로 다른 환경에서 우리가debian시스템에 대한 요구도 다르다. 예를 들어 생산 환경에서 우리는 시스템이 상당히 안정적이기를 희망한다. 이때stable가 가장 좋은 선택이다.새로운 기능, 새로운 소프트웨어를 시도하는 것을 좋아하는 사용자에게는 테스트나 unstable가 더 적합할 수 있다.이러한 요구에 도달하려면, 우리는/etc/apt/sources에서list 파일에서 디스플레이 원본만 지정합니다. 예를 들어 stable 디스플레이 원본을 사용하려면sources에 있습니다.list에 stable 원본만 추가하면 시스템에 설치된 패키지 버전이 모두 stable 버전에 들어갑니다.그러나 가끔은 우리도 혼합된 시스템이 필요하다. 예를 들어 전체 시스템이 Stable인 전제에서 테스트 distribution에 있는 패키지를 사용하기를 희망한다. 이렇게 하면 stable/testing이 혼합된 시스템이다.이럴 때만 소스에 있다면.stesting 원본에 가입하고 apt-get install/upgrade를 사용하고 다른 옵션을 추가하지 않으면 우리가 원하는 효과를 얻을 수 없습니다. 왜냐하면 이 때 apt시스템은 설치된 모든 패키지에 100, 설치되지 않은 패키지에 500을 할당하고 다음 규칙을 적용하여 패키지의 버전을 선택하기 때문입니다.
  • Never downgrade unless the priority of an available version exceeds 1000. ("Downgrading"is installing a less recent version of a package in place of a more recent version. Note that none of APT's default priorities exceeds 1000; such high priorities can only be set in the preferences file. Note also that downgrading a package can be risky.)
  • Install the highest priority version.
  • If two or more versions have the same priority, install the most recent one (that is, the one with the higher version number).
  • If two or more versions have the same priority and version number but either the packages differ in some of their metadata or the —reinstall option is given, install the uninstalled one.

  • 분명히 대부분의 경우 테스트 버전이 선택될 것입니다. 이것은 우리가 기대하는 것이 아닙니다.apt-get의 - t 옵션으로 목표distribution을 지정할 수 있지만 매번 이 옵션을 지정하는 것은 너무 번거롭고 잊어버릴 위험도 있다. 그래서 APT::Default-Release라는 설정 매개 변수는 자연스럽게 생겨난다./etc/apt/apt.conf에서 이 매개 변수를 stable로 설정하면 apt 명령을 할 때마다 목표distribution이 지정되지 않으면 목표distribution은 stable이다.다른distribution을 조작해야 할 때 -t로 명확하게 지정하면 됩니다.APT:::Default-Release stable;이렇게 쓸 수도 있다.
    APT {   Default-Release stable; }; 
    목표distribution(APT::Default-Release로 지정하든 - t 매개 변수로 지정하든)을 지정하면 apt는 다음 알고리즘으로 우선순위를 할당합니다.
    priority 100
    to the version that is already installed (if any).
    priority 500
    to the versions that are not installed and do not belong to the target release.
    priority 990
    to the versions that are not installed and belong to the target release.
     
    또한/etc/apt/preferences의 설정도 우선순위 분배에 영향을 줄 수 있습니다.
    references:
  • man apt_preferences
  • APT HOWTO
  • Debian's Developer's Reference  
  • 좋은 웹페이지 즐겨찾기