3장. 데비안 배포판 선택

# 3장. 데비안 배포판 선택

여러 다른 데비안 배포판이 있습니다. 적절한 데비안 배포판 선택은 중요한 결정입니다. 이 절은 시스템에 가장 적절한 선택을 하는데 필요한 정보를 주고, 절차 중 생길 수 있는 질문에 답합니다. "데비안을 선택하는 까닭" 아니라 "데비안의 어느 배포판"을 다룹니다.

가능한 배포판에 대한 자세한 내용 6.1절. “데비안 배포판은 얼마나 많나요?”.

## 3.1. 어느 데비안 배포판(stable/testing/unstable)이 나에게 좋은가요?

대답은 약간 복잡합니다. 그것은 사실 당신이 하려는 것에 따라 다릅니다. 한 가지 해결책은 데비안을 사용하는 친구에게 물어보는 것입니다. 그러나, 그렇다고 해서 독립적인 결정을 내릴 수 없는 것은 아닙니다. 사실, 이 장을 다 읽으면 결정할 수 있을 겁니다.

- 보안이나 안정성이 중요하다면: stable 설치하십시오. 끝. 이것이 가장 권장하는 방법입니다.

- 데스크톱 컴퓨터에 설치하는 신규 사용자인 경우 stable로 시작하십시오. 일부 소프트웨어는 꽤 오래되었지만 작업하기에 버그가 가장 적은 환경입니다. 조금 더 자신감이 생기면 최신 unstable(또는 testing)으로 쉽게 전환할 수 있습니다.

- 운영 체제에 대한 많은 경험이 있는 데스크톱 사용자이고 때때로 이상한 버그가 발생하거나 전체 시스템이 손상되는 것을 걱정하지 않는다면 unstable 사용하십시오. 모든 최신 소프트웨어가 있으며 버그는 대개 빨리 고칩니다.

- 서버, 특히 강력한 안정성 요구 사항이 있거나 인터넷에 노출된 서버를 실행 중인 경우 stable 설치하십시오. 이것이 지금까지 가장 강력하고 안전한 선택입니다.

다음 질문은 이러한 선택에 대한 자세한 정보를 제공합니다. 이 전체 FAQ를 읽은 후에도 여전히 결정을 내릴 수 없다면 stable 배포판을 고르시오.

### 3.1.1. 요청은 stable 설치 하라고 하지만, stable에서 하드웨어가 감지/동작하지 않습니다. 어떻게 하나요?

검색 엔진을 사용하여 웹을 검색하고 다른 사람이 안정적으로 동작하도록 할 수 있는지 확인하십시오. 대부분의 하드웨어는 안정적으로 잘 동작해야 합니다. 그러나 최첨단 하드웨어가 있으면 stable에서 동작하지 않을 수 있습니다. 이 경우 testing 또는 unstable로 설치/업그레이드할 수 있습니다.

랩톱에서 https://www.linux-on-laptops.com/은 다른 사람이 리눅스에서 동작하게 할 수 있는지 확인할 수 있는 매우 좋은 웹사이트입니다. 이 웹사이트는 데비안에만 국한된 것은 아니지만, 엄청난 재료입니다. 나는 데스크톱 용 웹사이트는 모릅니다.

다른 옵션은 debian-user@lists.debian.org로 전자메일 보내서 debian-user 메일링 리스트에 요청하는 것입니다. 메시지를 구독하지 않아도 목록에 게시할 수 있습니다. 아카이브는 https://lists.debian.org/debian-user/ 통해 읽을 수 있습니다 . 목록 구독에 대한 정보는 아카이브 위치에서 찾을 수 있습니다. 질문을 irc 아니고 메일링 리스트에 게시하는 것을 강력 추천합니다 . 메일링 리스트 메시지는 보관되므로 문제에 대한 해법이 같은 문제를 가진 다른 사람을 도울 수 있습니다.

### 3.1.2. 다른 배포판에 다른 버전 패키지가 있나요?

예. unstable에는 가장 최신(최근) 버전이 있습니다. 그러나 unstable에 있는 패키지는 잘 테스트되지 않았으며 버그가 있을 수 있습니다.

반면, stable 패키지에는 이전 버전의 패키지가 들어 있습니다. 그러나 이 패키지는 잘 테스트 되었으며 버그가 있을 가능성이 적습니다.

패키지 중 testing에 있는 것은 이 두 극단 사이에 있습니다.

### 3.1.3. stable 배포판에는 실제로 오래된 패키지가 들어 있습니다. Kde, Gnome, Xorg 또는 커널을 살펴보십시오. 아주 오래되었습니다. 왜 그런가요?

글쎄, 당신이 맞을 수도 있습니다. stable 패키지의 수명은 마지막 릴리스가 만들어진 시기에 따라 다릅니다. 릴리스 사이에는 대개 1년 이상 있으므로 stable 패키지에 이전 버전의 패키지가 들어 있음을 알 수 있습니다. 그러나 그것은 안팎으로 테스트되었습니다. 패키지에는 알려진 심각한 버그, 보안 허점 등이 없다고 자신 있게 말할 수 있습니다. stable 패키지는 다른 stable 패키지와 원활하게 통합됩니다. 이러한 특성은 하루 24시간, 주 7일 동작해야 하는 프로덕션 서버에 매우 중요합니다.

한편, testing 또는 unstable 패키지에 숨겨진 버그, 보안 구멍 등이 있을 수 있습니다. 게다가 testing 및 unstalbe은 기대한 대로 동작하지 않을 수 있습니다.

보는 바와 같이, 안정성과 새로움은 스펙트럼의 양 끝입니다. 안정성이 필요하면: stable 배포판을 설치하십시오. 최신 패키지로 작업하려면 unstable 설치하십시오.

### 3.1.4. 다른 배포판으로 바꾸기로 결정했다면, 내가 할 수 있나요?

예, 하지만 단방향 프로세스입니다. stable --> testing --> unstable 가능합니다. 그러나 반대 방향은 "가능"하지 않습니다. 따라서 unstable 설치/업그레이드할 계획인지 확인하는 것이 좋습니다.

사실, 당신이 전문가이고 시간을 할애할 의향이 있고 정말로 조심하고 무엇을 하고 있는지 안다면 unstable에서 testing으로, 그리고 stable로 갈 수 있습니다. 설치프로그램 스크립트는 그렇게 하도록 설계되지 않았습니다. 따라서 이 과정에서 구성 파일을 잃을 수 있으며...

### 3.1.5. 나에게 stable, testing 또는 unstable 중에 무엇을 설치할 지 말해주시겠어요?

아뇨. 그건 주관적 이슈입니다. 소프트웨어 요구 사항, 파손 가능성에 대한 대처 의지, 시스템 관리 경험에 따라 달라지므로 완벽한 답은 없습니다. 다음은 몇 가지 팁:

- stable은 견고합니다. 깨지지 않고 완벽한 보안 지원을 제공합니다. 그러나 최신 하드웨어를 지원하지 않을 수 있습니다.

- testing에는 stable 보다 최신 소프트웨어가 있으며 unstable보다 덜 깨집니다. 하지만, 그것이 깨지면 문제를 해결하는 데 오랜 시간이 걸릴 수 있습니다. 때로는 이것이 며칠이 될 수도 있고 때로는 몇 달이 될 수도 있습니다. 영구적인 보안 지원을 제공하지도 않습니다.

- Unstable은 최신 소프트웨어를 갖고 있으며 많이 바뀝니다. 결과적으로, 어디서나 깨질 수 있습니다. 그러나, 고친 것은 며칠 안에 여러 번 수정되며 항상 데비안용으로 패키지된 최신 소프트웨어 릴리스가 있습니다.

testing 및 unstable 사이에서 결정할 때 testing을 추적하는 것이 unstable 보다 좋을 때가 있을 수 있다는 점을 주의하십시오. 이 문서의 작성자 중 한 명이 gcc3에서 gcc4로의 gcc 전환으로 인해 이러한 상황을 경험했습니다. 그는 unstable을 추적하는 컴퓨터에 `labplot` 를 설치하려 했습니다. unstable에 설치할 수 없었는데, 왜냐면 종속성 중 일부가 gcc4 전환을 거쳤고 일부는 그렇지 않았기 때문. 그러나 testing에 있는 패키지는 testing 컴퓨터에 설치가능했는데, 왜냐면 gcc4로 전환된 패키지가 테스트로 "trickled down" 안 되었기 때문.

### 3.1.6. testing이 깨지는 것에 대해 말합니다. 저건 무슨 뜻이죠?

때때로, 패키지 관리 도구를 통해 패키지를 설치하지 못할 수 있습니다. 때로는, 패키지를 전혀 사용할 수 없거나, 버그 또는 충족되지 않은 종속성으로 인해 (일시적으로) 제거되었을 수 있습니다. 때로는, 패키지가 설치되지만 제대로 동작하지 않습니다.

이러한 일이 생기면 배포판이 깨졌다고 합니다(적어도 이 패키지는).

### 3.1.7. 왜 testing이 몇 달 동안 깨질 수 있나요? unstable 흐름에 도입된 수정 사항이 testing에 직접 적용되지 않나요?

unstable 배포판에 도입된 버그 수정 및 개선 사항은 일정 기간이 지나면 테스트 단계까지 이어집니다. 이 임계값이 5일이라고 가정해 보겠습니다. 불안정한불안정한 배포판에 도입된 버그 수정 및 개선 사항은 일정 기간이 지나면 테스트 단계까지 이어집니다. 이 임계값이 5일이라고 가정해 보겠습니다. unstable 패키지는 RC 버그가 보고되지 않은 경우에만 테스트에 들어갑니다. 불안정한 패키지에 대해 RC-버그가 있으면 5일 후에 테스트에 들어가지 않습니다.

아이디어는 그렇습니다. 만약 패키지가 문제 있으면 unstable 쓰는 사람이 발견할 거고 testing에 들어가기 전에 고칠 거다. 이것이 testing을 쓸 수 있는 상태로 대부분 시간 동안 유지한다. 전반적으로 좋은 개념, 만약 나에게 물어본다면. 그러나, 모든 게 늘 간단하지는 않습니다. 고려할 상황:

- 패키지 XYZ에 관심있다고 합시다.

- 6월 10일에 testing 버전이 XYZ-3.6이고 unstable 버전이 XYZ-3.7이라고 가정해 보겠습니다.

- 5일 후, XYZ-3.7이 unstable 마이그레이션이 testing으로 들어갑니다.

- 그래서, 6월 15일에 testing 및 unstable 모두 저장소에 XYZ-3.7이 있습니다.

- 예를들어, testing 배포 사용자가 새 XYZ 패키지를 사용할 수 있음을 확인하고 XYZ-3.6을 XYZ-3.7로 업데이트한다고 가정합니다.

- 이제 6월 25일에 testing 또는 unstable 사용자가 XYZ-3.7에서 RC 버그를 발견하고 BTS에 신고합니다.

- XYZ의 메인테이너가 이 버그를 수정하여 6월 30일에 unstable에 업로드했다고 합시다. 여기서는 메인테이너가 버그를 수정하고 새 버전을 업로드하는 데 5일이 걸린다고 가정합니다. 숫자 5를 문자 그대로 받아들이면 안 됩니다. 당면한 RC 버그의 심각도에 따라 적거나 많을 수 있습니다.

- unstable에 있는 이 새 버전 XYZ-3.8은 7월 5일에 testing에 들어갈 예정입니다.

- 그러나 7월 3일 다른 사람이 XYZ-3.8에서 또 다른 RC 버그를 발견합니다.

- XYZ의 관리자가 이 새로운 RC 버그를 수정하고 5일 후에 새 버전의 XYZ를 업로드한다고 가정해 보겠습니다.

- 따라서 7월 8일에 testing에는 XYZ-3.7이 있고 unstable에는 XYZ-3.9가 있습니다.

- 이 새 버전 XYZ-3.9는 이제 7월 13일에 testing에 들어가도록 일정이 변경되었습니다.

- 이제 testing을 실행 중이고, XYZ-3.7에 버그가 있으므로, 7월 13일 이후에만 XYZ를 사용할 수 있습니다. 그것은 당신이 본질적으로 약 한 달 동안 깨진 XYZ로 끝났다는 것입니다.

상황이 훨씬 더 복잡해질 수 있습니다. 예를 들어 XYZ는 4개의 다른 패키지에 의존합니다. 이로 인해 몇 달 동안 사용할 수 없는 testing 배포가 발생할 수 있습니다. 위의 시나리오는 상상이지만, 비슷한 일이 현실에서 드물더라도 일어날 수 있습니다.

### 3.1.8. 관리자 관점에서 더 주의가 필요한 배포는 무엇인가요?

많은 사람이 다른 리눅스 배포판보다 데비안을 선택하는 주된 이유 중 하나는 관리가 거의 필요하지 않기 때문입니다. 제대로 동작하는 시스템을 원합니다. 일반적으로 stable은 유지 관리가 거의 필요하지 않지만 testing 및 unstable은 관리자가 지속적인 유지 관리해야 합니다. stable을 실행 중이라면 보안 업데이트를 추적하기만 하면 됩니다. testing 또는 unstable을 쓰면 설치된 패키지에서 발견된 새로운 버그, 새로운 버그 수정/기능 도입 등을 알고 있는 것이 좋습니다.

### 3.1.9. 새 릴리스를 만들면 어떻게 되나요?

이 질문은 데비안 배포판을 선택하는 데 도움이 되지 않습니다. 그러나 조만간 이 질문에 직면하게 될 것입니다.

stable 배포판은 현재 trixie. 다음 stable 배포판은 forky. forky가 새 stable 버전으로 릴리스되었을 때 어떤 일이 일어나는지 특별한 경우를 생각해 봅시다.

- oldstable = bookworm; stable = trixie; testing = forky; unstable = sid

- Unstable은 릴리스 여부에 관계없이 항상 sid라고 합니다.

- 패키지는 지속적으로 sid에서 testing(즉 forky)로 마이그레이트 됩니다. 그러나 stable 안의 패키지(trixie)는 보안 업데이트를 제외하고는 동일하게 유지됩니다.

- 얼마 후 testing은 동결됩니다. 그러나 여전히 testing 이라고 할 것입니다. 이 시점에서 RC(release-critical) 버그 수정이 없으면 unstable에 있는 새 패키지는 testing으로 마이그레이트 안 됩니다.

- testing이 동결되면, 릴리스 팀 구성원이 새로 도입된 모든 버그 수정을 수동으로 확인해야 합니다. 동결된 testing에서 알려지지 않은 심각한 문제가 없도록 하려고 이렇게 합니다.

- '동결된 testing'의 RC 버그는 0으로 줄거나 0보다 크면, 버그가 릴리스에 대해 무시된 것으로 표시되거나 포인트 릴리스에 대해 연기됩니다.

- rc-bug 없는 '프로즌 testing'은 새 stable 버전으로 릴리스 될 것입니다. 이 예에서 이 새로운 안정적인 릴리스는 forky.

- 이 단계에서 oldstable = trixie, stable = forky. 이 시점에서 stable 및 '동결된 testing' 내용은 같습니다.

- 새 testing은 old testing 기반입니다.

- 패키지가 sid에서 testing으로 내려오기 시작하고 데비안 커뮤니티는 다음 stable 릴리스를 만들려고 일합니다.

### 3.1.10. 데비안을 설치한 동작하는 데스크톱/클러스터가 있습니다. 실행 중인 배포판을 어떻게 아나요?

대부분의 상황에서 이것을 알아내는 것은 매우 쉽습니다. `/etc/apt/sources.list` 파일을 살펴보십시오. 다음과 유사한 항목이 있습니다:

    deb http://deb.debian.org/debian/ unstable main contrib

세 번째 필드(위의 예에서 'unstable')는 시스템이 현재 추적 중인 데비안 배포판을 나타냅니다.

lsb_release를 사용할 수도 있습니다 (`lsb-release` 패키지에서 가능). 이 프로그램을 unstable 시스템에서 실행하면 얻는 것:

    $ lsb_release  -a
    LSB Version:    core-2.0-noarch:core-3.0-noarch:core-3.1-noarch:core-2.0-ia32:core-3.0-ia32:core-3.1-ia32
    Distributor ID: Debian
    Description:    Debian GNU/Linux unstable (sid)
    Release:    unstable
    Codename:   sid

그러나 이것이 항상 쉬운 것은 아닙니다. 일부 시스템에는 `sources.list` 파일에 다른 배포판에 해당하는 여러 항목이 있을 수 있습니다 . 이것은 관리자가 다른 데비안 배포판에서 다른 패키지를 추적할 때 생길 수 있습니다. 이것을 흔히 apt-pinning이라고 합니다. 이러한 시스템은 배포판 혼합을 실행할 수 있습니다.

### 3.1.11. 현재 stable을 사용 중입니다. testing 또는 unstable로 바꿀 수 있나요? 그렇다면 어떻게?

우선, 안정 버전은 서버와 데스크톱 환경 모두에 권장되는 릴리스임을 명심하십시오. 안정 버전을 운영한다면 정기적인 보안 업데이트가 제공될 뿐 아니라, 시스템이나 사용자 설정에 오류를 일으킬 가능성이 있는 변경이 적습니다.

현재 stable 버전을 사용 중이라면, `/etc/apt/sources.list` 파일의 세 번째 필드는 'trixie' 또는 'stable'로 표시되어 있을 겁니다. 만약 다른 버전으로 바꾸고 싶다면, 이 부분을 사용하고자 하는 배포판 명칭으로 바꾸어야 합니다. testing 버전을 사용하려면 `/etc/apt/sources.list`의 세 번째 필드를 'testing'으로, unstable 버전을 사용하려면 'unstable'로 바꾸십시오.

현재 testing은 forky. `/etc/apt/sources.list` 파일의 3번째 필드를 'forky'로 바꾸면, testing을 실행합니다. 그러나 forky 이 stable로 될 때에도 forky을 추적합니다.

불안정은 항상 Sid라고 합니다. 따라서 `/etc/apt/sources.list` 파일의 세 번째 필드를 'sid'로 바꾸면 unstable을 추적합니다.

현재 데비안은 testing, unstable 대해 별도의 보안 업데이트를 제공하지 않습니다. 데비안 보안 팀은 주로 stable과 old-stable을 관리하는 데 집중하고 있습니다. 그러나, 다른 일반적인 수정 사항들과 마찬가지로, unstable의 보안 수정사항은 메인 아카이브에 직접 반영되며 적절한 절차를 거쳐 testing으로 전달됩니다. 따라서 만약 여러분이 unstable 버전을 사용 중이라면, `/etc/apt/sources.list` 파일에서 보안 업데이트와 관련된 라인을 반드시 지워야 합니다. 현재 이 버전들(testing 및 unstable)에 어떤 보안 버그가 있는지 알고 싶다면, 아래 링크를 통해 취약한 소스 패키지 목록을 확인할 수 있습니다. 이러한 버전의 배포판에 존재하는 알려진 보안 버그가 무엇인지 알고 싶으면, testing 안의 취약한 소스 패키지 목록, 및 unstable에서 이 정보를 보십시오.

업그레이드하려는 배포판의 릴리스 노트(Release Notes) 문서가 (아직 정식 출시 전이라 하더라도) 존재한다면, 이를 미리 검토해 보는 것이 현명합니다. 해당 문서에는 업그레이드 방법과 관련된 중요한 정보가 포함되어 있을 수 있기 때문입니다. 데비안 웹사이트에서는 언제든지 testing 링리스 노트를 확인할 수 있습니다. 다만, testing 버전이 실제 정식 출시일에 얼마나 가까운지에 따라, 해당 문서가 발생 가능한 모든 변경 사항이나 잠재적인 위험 요소(pitfalls)를 충분히 다루지 못할 수도 있다는 점을 유의해야 합니다.

그럼에도, 위와 같이 바꾸면, `aptitude update` 실행하고 그러면 원하는 패키지를 설치할 수 있습니다. 다른 배포판에서 패키지를 설치하면 시스템의 절반이 자동으로 업그레이드될 수 있습니다. 개별 패키지를 설치하면 혼합 배포판을 실행하는 시스템이 됩니다.

어떤 상황에서는 apt full-upgrade, aptitude safe-upgrade or aptitude full-upgrade를 실행하여 새 배포판으로 완전히 업그레이드하는 것이 가장 좋습니다 . 자세한 내용은 apt 및 aptitude의 매뉴얼 페이지 참조하십시오.

데비안 레퍼런스 매뉴얼의 Life with eternal upgrades 섹션에서 testing 및 unstable 버전에 관한 더 상세한 정보를 볼 수 있습니다.

### 3.1.12. 현재 testing (forky)을 추적하고 있습니다. 릴리스되면 어떻게 됩니까? testing을 계속 추적할 예정인가요, 아니면 내 컴퓨터에서 새로운 stable 배포판을 실행하나요?

그건 `/etc/apt/sources.list` 파일 항목에 달려있습니다. 현재 testing을 추적 중이라면, 이런 항목은 다음 중 하나와 비슷합니다:

    deb http://deb.debian.org/debian/ testing main

또는

    deb http://deb.debian.org/debian/ forky main

만약 `/etc/apt/sources.list` 파일의 3번째 필드가 'testing'이면 릴리스 만든 후에도 testing을 추척합니다. 그래서 forky이 릴리스 되면, 새 데비안 배포판을 실행하는데 다른 코드명을 가질 겁니다.바뀐 사항은 처음에는 명확하지 않을 수 있지만 unstable 패키지의 새 패키지가 testing 배포판으로 넘어가는 즉시 분명해질 겁니다.

그러나, 3째 필드에 'forky'가 들어있으면 stable을 추적합니다.(왜냐면 forky가 새 stable 배포판이 되므로)

### 3.1.13. 아직 헷갈립니다. 무엇을 설치해야 한다고 했나요?

불확실하다면, stable 배포판이 좋습니다.

## 3.2. 그러나 Kali, Knoppix, 리눅스 민트, 우분투 등은 무엇인가요?

그건 데비안이 아닙니다. 데비안 기반입니다. 비슷한 점 및 공통점이 있지만 결정적 차이도 있습니다.

지난 여러 해 동안, 데비안 패키지를 재사용하거나 재빌드하고 자체적인 커스텀 패키지를 추가하는 방식으로 수많은 배포판이 개발되어 왔습니다. 이러한 배포판의 대부분은 특정한 사용자층이나 목적을 위해 만들어졌습니다. Distrowatch에 따르면, 데비안은 420 파생 배포판을 탄생시켰으며, 이 글을 쓰는 시점을 기준으로 그중 120개 이상이 활발히 유지 관리되고 있습니다.

이 모든 배포판은 저마다의 장점을 가지고 있으며 특정 사용자층에 최적화되어 있습니다. 더 자세한 내용은 데비안 웹사이트에서 제공하는 Debian derivatives 참고하시기 바랍니다. 또한, 현재 개발이 중단된 프로젝트를 포함하여 데비안 파생 배포판의 전체 목록은 데비안 위키의 데비안 파생판 인구조사에서 확인하실 수 있습니다.

### 3.2.1. Kali/Knoppix/Linux Mint/Ubuntu/... 등이 데비안 기반이라는 것을 알고 있습니다. 하드디스크에 설치한 후, 거기에서 'apt' 패키지 도구를 사용할 수 있나요?

이 배포판은 데비안 기반이기는 하지만, 데비안은 아닙니다. `/etc/apt/sources.list` 파일이 해당 배포판의 저장소를 가리키도록 설정함으로써 여전히 apt 패키지 도구를 사용할 수 있습니다. 어떤 경우에는 일부 배포판이 apt 대신 사용하는 추가적인 패키지 관리자를 별도로 가지고 있을 수도 있습니다.

대부분의 상황에서 하나의 배포판을 고수하는 경우 다른 배포판의 패키지를 섞지 말고 이를 사용해야 합니다. 배포판을 실행하는 사람들과 다른 배포판의 데비안 패키지를 설치하려고 할 때 발생하는 많은 일반적인 손상이 있습니다. 동일한 형식과 이름(.deb)을 사용한다고 해서 즉시 호환되는 것은 아닙니다.

예를 들어, Knopix는 라이브 CD로 부팅되도록 설계된 리눅스 배포판인 반면, 데비안은 하드 디스크에 설치되도록 설계되었습니다. 특정 하드웨어가 동작하는지 알고 싶거나 GNU/리눅스 시스템이 어떤 '느낌'인지 등을 경험하고 싶다면 Knopix가 좋습니다. 데비안은 24시간 연중무휴로 실행되도록 설계된 반면, 사용 가능한 패키지 수와 데비안이 지원하는 아키텍처 수는 Knopix보다 훨씬 많습니다.

데비안을 원한다면 처음부터 데비안을 설치하는 것이 가장 좋습니다. Knoppix와 같은 다른 배포판을 통해 데비안을 설치하는 것도 가능하지만, 절차에는 전문 지식이 필요합니다. 이 FAQ를 읽고 계신다면 데비안과 크노픽스를 모두 처음 접하는 분이라고 생각합니다. 그런 상황이라면, 나중에 겪게 될 수많은 번거로움을 피하기 위해서라도 처음부터 데비안을 설치하는 것이 좋습니다.

### 3.2.2. Kali/Knoppix/Linux Mint/Ubuntu/... 등을 하드디스크에 설치했습니다. 그런데 문제가 발생했습니다. 어떻게 해야 하나요?

데비안 파생 배포판에 대한 도움을 얻기 위해 데비안 포럼(메일링 리스트나 IRC 등)을 이용하지 마십시오. 그곳의 사용자들은 귀하가 순정 데비안 시스템을 사용 중이라는 가정하에 해결책을 제시할 수 있기 때문입니다. 이러한 "해결책"은 여러분이 사용 중인 시스템에 적합하지 않을 수 있으며, 심지어 문제를 더 악화시킬 수도 있습니다.

먼저 여러분이 사용 중인 특정 배포판의 포럼을 이용하십시오. 만약 그곳에서 도움을 받지 못했거나, 받은 도움으로도 문제가 해결되지 않는다면 데비안 포럼에 질문을 올려볼 수도 있습니다. 하지만 이 경우 앞서 언급한 주의 사항(시스템이 순정 데비안과 다를 수 있다는 점)을 반드시 염두에 두십시오.

### 3.2.3. 나는 Kali/Knoppix/Linux Mint/Ubuntu/... 등을 쓰고 있고 지금 데비안 쓰고 싶어요. 어떻게 옮기죠?

데비안 기반 배포판에서 순수 데비안으로 바꾸는 것은 마치 한 운영체제에서 다른 운영체제로 바꾸는 것과 같습니다. 모든 데이터를 백업하고 운영체제를 처음부터 다시 설치해야 합니다. 패키지 관리 도구를 사용하여 데비안으로 "업그레이드"를 시도해서는 안 됩니다. 못쓰는 시스템이 될 수 있습니다.

사용자 데이터(즉, `/home` )가 별도의 파티션에 있다면, 데비안으로 마이그레이션하는 것은 사실 매우 간단합니다. 다시 설치할 때 설치 시스템에 해당 파티션을 마운트(포맷은 하지 않음)하도록 지시하기만 하면 됩니다. 물론, 데이터 백업은 물론 이전 시스템의 구성 파일(예: `/etc/` 및 경우에 따라 ``/var/`) 백업은 여전히 권장됩니다.

2장. Debian GNU/Linux 얻기 및 설치 |  | 4장. 호환성 이슈