3장. 데비안 배포판 선택

차례

3.1. 어느 데비안 배포판(stable/testing/unstable)이 나에게 좋은가요?
3.1.1. 요청은 stable 설치 하라고 하지만, stable에서 하드웨어가 감지/동작하지 않습니다. 어떻게 하나요?
3.1.2. 다른 배포판에 다른 버전 패키지가 있나요?
3.1.3. stable 배포판에는 실제로 오래된 패키지가 들어 있습니다. Kde, Gnome, Xorg 또는 커널을 살펴보십시오. 아주 오래되었습니다. 왜 그런가요?
3.1.4. 다른 배포판으로 바꾸기로 결정했다면, 내가 할 수 있나요?
3.1.5. 나에게 stable, testing 또는 unstable 중에 무엇을 설치할 지 말해주시겠어요?
3.1.6. testing이 깨지는 것에 대해 말합니다. 저건 무슨 뜻이죠?
3.1.7. 왜 testing이 몇 달 동안 깨질 수 있나요? unstable 흐름에 도입된 수정 사항이 testing에 직접 적용되지 않나요?
3.1.8. 관리자 관점에서 더 주의가 필요한 배포는 무엇인가요?
3.1.9. 새 릴리스를 만들면 어떻게 되나요?
3.1.10. 데비안을 설치한 작동하는 데스크톱/클러스터가 있습니다. 실행 중인 배포판을 어떻게 아나요?
3.1.11. I am currently using the stable version. Can I change to testing or unstable? If so, how?
3.1.12. 현재 testing (trixie)을 추적하고 있습니다. 릴리스되면 어떻게 됩니까? testing을 계속 추적할 예정인가요, 아니면 내 컴퓨터에서 새로운 stable 배포판을 실행하나요?
3.1.13. 아직 헷갈립니다. 무엇을 설치해야 한다고 했나요?
3.2. But what about Kali, Knoppix, Linux Mint, Ubuntu, and others?
3.2.1. I know that Kali/Knoppix/Linux Mint/Ubuntu/... is Debian-based. So after installing it on the hard disk, can I use 'apt' package tools on it?
3.2.2. I installed Kali/Knoppix/Linux Mint/Ubuntu/... on my hard disk. Now I have a problem. What should I do?
3.2.3. I'm using Kali/Knoppix/Linux Mint/Ubuntu/... and now I want to use Debian. How do I migrate?

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

가능한 배포판에 대한 자세한 내용 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 배포판은 현재 bookworm. 다음 stable 배포판은 trixie. trixie가 새 stable 버전으로 릴리스되었을 때 어떤 일이 일어나는지 특별한 경우를 생각해 봅시다.

  • oldstable = bullseye; stable = bookworm; testing = trixie; unstable = sid

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

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

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

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

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

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

  • 이 단계에서 oldstable = bookworm, stable = trixie. 이 시점에서 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. I am currently using the stable version. Can I change to testing or unstable? If so, how?

First of all, please bear in mind that the stable version is the one recommended for servers as well as for desktop computers, not only you will get security updates if you are running stable but also there are less changes which could potentially break the system or your setup.

If you are currently running stable, then in the /etc/apt/sources.list file the third field will be either 'bookworm' or 'stable'. If you want to change to a different version, you need to change this to the distribution you want to run. If you want to run testing, then change the third field of /etc/apt/sources.list to 'testing'. If you want to run unstable, then change the third field to 'unstable'.

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

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

Currently Debian offers does not offer security updates for testing nor for unstable. The Debian Security Team focus their work on stable and old-stable. Nevertheless, just like any other type of fixes, security fixes in unstable are directly made to the main archive and trickle down to testing in due course. So if you are running unstable make sure that you remove the lines relating to security updates in /etc/apt/sources.list. If you are interested in knowing what known security bugs exist in these versions of the distributions, you will this information in the list of vulnerable source packages in testing, and unstable.

If there is a release notes document available for the distribution you are upgrading to (even though it has not yet been released) it would be wise to review it, as it might provide information on how you should upgrade to it. You will always find the Release Notes for testing available at the Debian website but depending on how close the testing version is to release the document might not cover all the potential changes or pitfalls.

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

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

The Debian reference manual provides more insight on running testing and unstable in its section Life with eternal upgrades.

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

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

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

또는

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

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

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

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

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

3.2. But what about Kali, Knoppix, Linux Mint, Ubuntu, and others?

These distributions are not Debian; they are Debian-based. Though there are many similarities and commonalities between them, there are also crucial differences.

Over the years, many distributions have been developed over time reusing and/or rebuilding Debian packages and also adding custom packages on their own. Most of the distributions have been created for specific audiences or purposes. According to Distrowatch, Debian has spawned more than 420 derivatives and more than 120 of them are active at the time of writing.

All these distributions have their own merits and are suited to some specific set of users. For more information, read Debian derivatives available at the Debian website. You can find a complete list of Debian derivatives, including those that are no longer under active development at the Debian derivate Census in the Wiki.

3.2.1. I know that Kali/Knoppix/Linux Mint/Ubuntu/... is Debian-based. So after installing it on the hard disk, can I use 'apt' package tools on it?

These distributions are Debian-based, but they are not Debian. You will be still able to use apt package tools by pointing the /etc/apt/sources.list file to these distributions' repositories. In some cases some distributions might even have additional package managers that are used instead of apt.

In most situations if you stick with one distribution you should use that and not mix packages from other distributions. Many common breakages arise due to people running a distribution and trying to install Debian packages from other distributions. The fact that they use the same formatting and name (.deb), does not make them immediately compatible.

For example, Knoppix is a Linux distribution designed to be booted as a live CD whereas Debian is designed to be installed on the hard-disk. Knoppix is great if you want to know whether a particular piece of hardware works, or if you want to experience how a GNU/Linux system 'feels' etc., Knoppix is good for demonstration purposes while Debian is designed to run 24/7. Moreover the number of packages available and the number of architectures supported by Debian are far more than that of Knoppix.

If you want Debian, it is best to install Debian from the get-go. Although it is possible to install Debian through other distributions, such as Knoppix, the procedure calls for expertise. If you are reading this FAQ, I would assume that you are new to both Debian and Knoppix. In that case, save yourself a lot of trouble later and install Debian right from the beginning.

3.2.2. I installed Kali/Knoppix/Linux Mint/Ubuntu/... on my hard disk. Now I have a problem. What should I do?

You are advised not to use the Debian forums (either mailing lists or IRC) for help on Debian derivatives as people there may base their suggestions on the assumption that you are running a Debian system. These "fixes" might not be suited to what you are running, and might even make your problem worse.

Use the forums of the specific distribution you are using first. If you do not get help or the help you get does not fix your problem you might want to try asking in Debian forums, but keep the advice of the previous paragraph in mind.

3.2.3. I'm using Kali/Knoppix/Linux Mint/Ubuntu/... and now I want to use Debian. How do I migrate?

Consider the change from a Debian-based distribution to Debian just like a change from one operating system to another one. You should make a backup of all your data and reinstall the operating system from scratch. You should not attempt to "upgrade" to Debian using the package management tools as you might end up with an unusable system.

If all your user data (i.e. your /home) is under a separate partition migrating to Debian is actually quite simple, you just have to tell the installation system to mount (but not reformat) that partition when reinstalling. Making backups of your data, as well as your previous system's configuration (i.e. /etc/ and, maybe, /var/) is still encouraged.