Devuan

Debian의 init 전환

Debian은 오랫동안 SysVinit을 기본 init으로 사용했으나, 2014년 2월 11일 Debian 기술위원회가 당시 개발 중이던 Debian 8 Jessie의 Linux 아키텍처에서 systemd를 기본 init으로 선택했다. 이후 Debian 내부에서는 기본 init 선택뿐 아니라 패키지가 특정 init 시스템에 어느 정도 의존할 수 있는지, 다른 init을 계속 지원할지, systemd 구성 요소를 어느 범위까지 기본 시스템에 포함할지를 두고 논의가 이어졌다.^[11][12]

이 논쟁에서 systemd 채택에 반대하거나 다른 init의 지속적인 사용 가능성을 중시한 일부 관리자와 개발자는, Debian의 새 기본 구성이 기존 UNIX식 도구 분리와 init 선택권을 약화한다고 보았다. Devuan은 systemd 자체의 개발을 막는 프로젝트가 아니라, systemd를 사용하지 않는 Debian 호환 선택지를 별도로 유지하는 방식으로 출발했다. Debian은 이후에도 systemd를 기본값으로 유지했으며 2019년 일반결의에서 여러 init 시스템에 대한 지원 방향을 다시 논의했다.^[13]

포크 선언

Veteran Unix Admins, 약칭 VUA를 자칭한 집단은 2014년 11월 27일 DNG 메일링 리스트에 Debian 포크를 발표했다. 초기 선언은 신뢰할 수 있고 최소화된 기본 시스템, Debian과의 후방 호환성 및 상호운용성, systemd와 그 필수 의존성의 제거, 수정 패키지의 재빌드, 독자적인 저장소·버그 추적·소스 관리·지속적 통합 인프라 구축을 목표로 제시했다.^[14]

프로젝트 이름 Devuan은 Debian에서 갈라진 새 계통을 나타내는 이름으로 채택되었다. 프로젝트는 처음부터 완성된 데스크톱 배포판 하나만 만드는 것보다 다른 배포판과 장치가 재사용할 수 있는 보편적인 기반 운영체제를 제공하는 방향을 강조했다. Dyne.org 재단은 초기 행정·재정·인프라 지원을 맡았고, Devuan 상표도 Dyne.org 재단에 등록되어 있다.^[15][16]

초기 인프라와 개발

포크 선언 직후 Devuan은 자체 Git 저장소, Jenkins 빌드 시설, 패키지 아카이브와 버그 추적 체계를 준비했다. 2014년 12월 공개된 개발 소식은 git → Jenkins → dak로 이어지는 코드·빌드·패키징 흐름을 설명했으며, systemd에 종속되지 않는 ConsoleKit2, 로그인 관리 호환 계층, eudev와 vdev 등의 대안을 조사하고 있다고 밝혔다.^[17]

2015년 2월에는 초기 pre-alpha 이미지가 공개되었고, 이후 Debian Jessie 패키지를 기반으로 systemd 의존성을 제거하거나 대체하는 작업이 진행되었다. 설치 이미지, 패키지 저장소, ARM 이미지, 라이브 시스템, Devuan SDK와 패키지 병합 도구가 병행 개발되면서 단순한 패키지 묶음에서 독립적으로 설치하고 유지할 수 있는 배포판으로 발전했다.^[18]

첫 안정판 Jessie

첫 안정판 Devuan 1 Jessie는 2017년 5월 25일 공개되었다. Debian 포크 선언 뒤 약 2년 반에 걸친 개발 결과로, Debian 8 Jessie와 호환되는 systemd 비의존 기반을 제공하고 Debian Wheezy 및 Jessie에서의 이전 경로를 지원하는 것이 핵심 목표였다. 이 릴리스에는 설치 ISO, desktop-live, minimal-live, 임베디드 이미지, Refracta 도구, debbugs 기반 버그 추적과 자체 패키지 저장소가 포함되었다.^[19]

ASCII 이후의 확장

Devuan 2 ASCII는 2018년 6월 8일 공개되어 Debian 9 Stretch를 기반으로 했다. ASCII에서는 SysVinit뿐 아니라 OpenRC를 설치 과정에서 선택할 수 있게 되었고, systemd에서 분리된 eudev와 elogind가 배포판 구성에 자리 잡았다. 미러 네트워크와 ARM 이미지 지원도 정비되었다.^[20]

Devuan 3 Beowulf는 2020년 6월 1일 공개되어 Debian 10 Buster와 Linux 4.19 계열을 기반으로 했다. 이 릴리스에서 ppc64el이 주요 아키텍처에 추가되었고, runit을 PID 1로 선택하는 구성이 공식 선택지에 들어왔다. OpenRC는 서비스와 런레벨 관리 계층으로 계속 제공되었으며 eudev와 elogind가 systemd와 분리된 구성 요소로 사용되었다.^[21]

Devuan 4 Chimaera는 2021년 10월 14일 공개되어 Debian 11 Bullseye와 Linux 5.10 계열을 기반으로 했다. SysVinit, runit, OpenRC 선택을 유지하면서 Debian에서 제공되는 대부분의 데스크톱 환경을 systemd를 PID 1로 사용하지 않고 설치할 수 있도록 패키지를 정비했고, 음성 합성과 점자 디스플레이를 포함한 설치 접근성도 강화했다.^[22]

Devuan 5 Daedalus는 2023년 8월 14일 공개되어 Debian 12 Bookworm과 Linux 6.1 계열을 기반으로 했다. libseat1을 이용한 루트 권한 없는 startx 실행과 elogind 없이도 가능한 일부 Wayland 구성을 지원하는 등 그래픽 세션 계층의 선택 폭을 넓혔다.^[23]

Devuan 6 Excalibur는 2025년 11월 2일 공개되어 Debian 13 Trixie와 Linux 6.12 계열을 기반으로 한다. 병합된 /usr 구성이 필수가 되었고, 설치·업그레이드·Debian Trixie에서의 마이그레이션 문서와 여러 설치 매체가 함께 제공되었다. Excalibur 뒤를 잇는 Devuan 7의 코드명은 Freia이며 현재 testing 저장소에서 개발되고 있다.^[24][25]

Init Freedom

Devuan이 사용하는 Init Freedom은 사용자가 PID 1, 서비스 관리기와 관련 사용자 공간 구성 요소를 선택할 수 있어야 한다는 원칙이다. 공식 설명은 이 원칙을 이식성, 다양성, 선택의 자유와 연결하며, SysVinit을 기본값으로 두면서 OpenRC와 runit을 공식적으로 제공한다.^[26]

이 원칙은 모든 구성 요소를 반드시 가장 작게 만들거나 하나의 특정 UNIX 설계를 강제한다는 뜻은 아니다. 실제 Devuan은 Debian의 현대적인 패키지와 데스크톱 환경을 최대한 재사용하면서, 부팅과 서비스 관리가 systemd 하나에 필수적으로 묶이지 않도록 패키지 수준에서 조정한다. 사용자는 전통적인 SysV 스크립트 중심 구성, 의존성 기반 OpenRC 구성, 서비스 감독을 중시하는 runit 구성 가운데 목적에 맞는 방식을 선택할 수 있다.

Debian 호환 기반

프로젝트의 또 다른 목표는 Debian 사용자와 파생 배포판이 기존 도구와 지식을 최대한 유지할 수 있게 하는 것이다. Devuan은 deb, APT, dpkg, Debian식 패키지 이름, 아카이브 구성, tasksel, Debian Installer 계통과 안정판 중심 릴리스 모델을 사용한다. 이 때문에 Debian에 익숙한 관리자는 저장소와 init 관련 차이를 이해하면 기존 운영 절차의 상당 부분을 그대로 적용할 수 있다.^[27][28]

Devuan은 Debian의 모든 패키지를 자체적으로 다시 설계하지 않는다. 수정이 필요 없는 패키지는 Debian 쪽 패키지를 사용하고, systemd 의존성이나 배포판 식별·설치·부팅 차이 때문에 수정이 필요한 패키지만 Devuan 소스 저장소에서 별도로 관리한다. 이 선택은 호환성을 높이고 유지 범위를 줄이는 대신, 대응 Debian 릴리스와 패키지 흐름에 상당 부분 의존하는 구조를 만든다.^[29]

이식성과 구성 가능성

Devuan은 systemd가 Linux에 밀접하게 결합되어 다른 UNIX 계열 운영체제로 직접 이식되기 어렵다는 점을 Init Freedom의 근거 중 하나로 든다. SysV 스타일 스크립트, OpenRC와 runit 같은 비교적 독립적인 구성 요소를 유지하면 Linux 배포판 사이뿐 아니라 BSD와 다른 UNIX 계열에서 축적된 관리 방식과 개념을 공유하기 쉽다는 관점이다.^[30]

이 배포판은 완성된 데스크톱 제품인 동시에 다른 시스템을 만드는 기반을 지향한다. 최소 설치, 라이브 이미지, 임베디드 장치, 가상 머신과 파생 배포판 제작 도구가 함께 제공되는 이유도 사용자가 목적에 맞게 사용자 공간과 init 구성을 조립할 수 있게 하기 위해서다.^[31]

자유 소프트웨어

Devuan 저장소의 main 구성 요소에는 자유 소프트웨어가 들어간다. 배포판 전체가 하나의 단일 라이선스를 사용하는 것은 아니며, 각 패키지는 GPL, LGPL, BSD, MIT 등 개별 자유 소프트웨어 라이선스를 따른다. 필요한 하드웨어와 소프트웨어를 위해 사용자가 non-free-firmware, non-free, contrib 구성 요소를 명시적으로 추가할 수도 있다.^[32][33]

릴리스 대응

Devuan의 안정판은 대체로 같은 세대의 Debian 안정판을 기반으로 한다. Jessie는 Debian 8 Jessie, ASCII는 Debian 9 Stretch, Beowulf는 Debian 10 Buster, Chimaera는 Debian 11 Bullseye, Daedalus는 Debian 12 Bookworm, Excalibur는 Debian 13 Trixie와 대응한다. 다만 Debian과 Devuan의 출시일은 같지 않으며, Devuan은 기반 Debian 릴리스가 나온 뒤 포크 패키지와 설치·마이그레이션 경로를 검증해 별도로 안정판을 공개한다.^[34]

Devuan의 testing과 unstable도 Debian의 개발 흐름과 연결된다. Freia는 Debian Forky를 기반으로 하는 다음 testing이고, Ceres는 Debian Sid에 대응하는 지속 개발 계열이다. 현재 testing이 안정판으로 승격되면 이전 stable은 oldstable로 이동하고, unstable의 스냅샷을 바탕으로 다음 testing이 만들어지는 구조를 사용한다.^[35]

패키지 재사용과 포크

Debian 패키지가 systemd에 필수적으로 의존하지 않고 Devuan 환경에서 그대로 동작하면 Devuan은 이를 별도 포크 없이 사용할 수 있다. 반대로 init 스크립트, 장치 관리, 로그인 세션, 부팅, 설치기, 배포판 식별 또는 의존성 수정이 필요한 패키지는 Devuan 전용 소스 저장소에서 관리한다. 공식 소스 코드 안내는 변경된 각 패키지가 devuan-packages 영역에 자체 저장소를 가진다고 설명한다.^[36]

이 방식은 Debian 전체 아카이브의 복사본을 독립적으로 유지하는 대신 변경점에 집중한다. 사용자가 보는 merged 저장소에는 Debian에서 가져온 패키지와 Devuan이 포크하거나 새로 제공한 패키지가 하나의 릴리스 관점으로 결합되어 나타난다. Devuan 전용 또는 제안 단계 패키지는 별도의 devuan 저장소 영역을 사용할 수 있다.^[37]

저장소를 직접 혼합하지 않는 이유

Debian과 Devuan은 높은 호환성을 갖지만 저장소를 임의로 함께 등록하는 방식은 공식적으로 지원되지 않는다. Devuan은 Debian·Ubuntu·Linux Mint 등의 저장소를 직접 추가하지 말고 Devuan의 병합 저장소를 사용하라고 안내한다. Devuan 측 패키지가 Debian의 같은 이름 패키지를 대체하거나 특정 버전을 전제로 의존성을 조정할 수 있기 때문에, 저장소를 직접 섞으면 의도한 우선순위와 포크 패키지가 무너질 수 있다.^[38]

Debian 버그와 Devuan 버그

수정하지 않은 Debian 패키지에서 발생한 문제는 Debian 원본 패키지의 버그일 수 있으며, Devuan 전용 패치·저장소·설치기·init 통합에서 발생한 문제는 Devuan 버그 추적 시스템의 대상이 된다. Devuan 설치 안내는 문제를 제출하기 전에 upstream Debian 문제인지 확인하고, Devuan 고유 문제일 때 Devuan BTS에 보고하도록 안내한다.^[39]

Amprolla

Amprolla는 Devuan 저장소 구조의 핵심 도구로, 여러 APT 저장소의 메타데이터를 병합해 사용자에게 일관된 Devuan 패키지 아카이브를 제공한다. Devuan 개발 문서는 Amprolla를 Debian 계통 패키지와 Devuan 수정 패키지를 최소한의 모듈식 방식으로 결합하는 배포판의 중심 구성 요소라고 설명한다.^[40]

소스와 지속적 통합

Devuan 고유 패키지와 포크 패키지의 소스는 공식 Git 저장소에서 관리된다. Jenkins 기반 지속적 통합은 소스 변경을 빌드해 패키지 아카이브로 전달하는 역할을 하며, 초기부터 git → Jenkins → dak 형태의 자동화된 흐름을 구축했다. 현재 개발 페이지에서도 Git 저장소, Jenkins와 Amprolla를 주요 인프라로 제시한다.^[41][42]

배포판 전용 패키지

Devuan 전용 패키지는 배포판 식별, 기본 설정, 키링, 저장소 설정, 설치기, init 통합, eudev 및 elogind 계통, 라이브 이미지와 SDK 등 Debian과 차이가 필요한 영역에 집중된다. 패키지 수준에서 systemd 의존성을 제거할 수 없는 경우에는 해당 패키지를 수정하거나 대체하고, 현재 릴리스에 적합하지 않은 패키지는 공식 목록에서 제외될 수 있다. 설치 페이지는 원하는 패키지가 보이지 않을 때 패키지 검색과 banned packages 목록을 확인하도록 안내한다.^[43]

패키지 정보 서비스

pkginfo.devuan.org는 Devuan 저장소의 패키지 버전, 설명, 파일, 의존 관계 등을 확인하는 검색 인터페이스다. APT의 policy와 show, apt-file, 의존성 트리 계통 정보를 웹에서 조회할 수 있어 특정 패키지가 어느 릴리스와 저장소에서 제공되는지, Devuan 포크인지 확인하는 데 사용된다.^[44]

Linux 커널과 사용자 공간

Devuan은 자체 커널 계통을 개발하는 운영체제가 아니라 Linux 커널 위에 GNU 및 Debian 계통 사용자 공간을 구성한 배포판이다. Excalibur의 기준 커널은 Linux 6.12 계열이며, 커널·컴파일러·라이브러리·데스크톱 응용 프로그램의 대부분은 대응 Debian 릴리스와 같은 기반에서 온다. Devuan의 차이는 주로 PID 1과 서비스 관리, 장치 관리자, 세션 관리, 패키지 의존성, 저장소와 설치 절차에 있다.^[45]

부팅 과정

일반적인 Devuan 부팅은 펌웨어와 부트로더가 Linux 커널 및 초기 RAM 파일 시스템을 적재하고, 커널이 루트 파일 시스템을 준비한 뒤 선택된 init을 PID 1로 실행하는 순서로 진행된다. 기본 구성에서는 SysVinit이 /etc/inittab, 런레벨과 /etc/init.d 스크립트를 바탕으로 서비스를 시작하고 종료한다. OpenRC 또는 runit을 선택하면 PID 1과 서비스 활성화 방식이 해당 구현에 맞게 달라진다.

init 선택은 단순히 부팅 프로그램 한 파일만 바꾸는 문제가 아니다. 서비스 단위의 시작·종료 스크립트, 의존 관계, 감독 방식, 로그 처리, 종료 순서와 복구 방식이 함께 달라질 수 있다. Devuan은 패키지에 전통적인 init 스크립트와 대체 init용 구성을 제공해 동일한 사용자 공간에서 여러 방식을 사용할 수 있도록 한다.^[46]

장치 관리

Devuan은 ASCII 이후 eudev를 장치 관리자로 사용해 왔다. eudev는 Linux 커널의 장치 이벤트를 받아 /dev 노드를 만들고 규칙을 적용하는 udev 계통 구현이면서, systemd 전체를 필수로 요구하지 않도록 분리된 형태다. 공식 Init Freedom 문서는 mdev와 vdev도 대안 장치 관리기로 언급한다.^[47]

장치 관리자는 init과 역할이 다르다. init은 PID 1과 서비스 수명 주기를 담당하고, eudev는 커널이 알린 하드웨어 및 가상 장치 이벤트를 처리한다. Devuan은 이 기능들을 하나의 통합 제품으로 묶기보다 필요에 따라 교체 가능한 구성 요소로 유지하려는 방향을 취한다.

로그인과 사용자 세션

그래픽 데스크톱에서는 전원 관리, 좌석, 활성 세션과 장치 접근 권한을 다루는 로그인 세션 계층이 필요하다. Devuan은 systemd-logind에 직접 의존하지 않는 구성을 위해 elogind와 libseat 같은 구성 요소를 활용한다. elogind는 logind 계통 기능을 독립적으로 제공하며, Daedalus에서는 libseat1을 통한 루트 없는 startx와 일부 elogind 비의존 Wayland 구성이 강조되었다.^[48]

모든 데스크톱이 같은 세션 관리 조합을 요구하는 것은 아니다. 디스플레이 서버, 로그인 관리자, 데스크톱 환경과 좌석 관리 백엔드에 따라 elogind를 사용할 수도 있고 libseat 계통을 사용할 수도 있다. Devuan의 패키지 정책은 가능한 경우 이러한 선택이 PID 1의 구현과 불필요하게 결합되지 않도록 하는 데 초점을 둔다.

병합된 /usr

Excalibur에서는 merged-usr, 즉 /bin, /sbin, /lib 계열을 /usr 아래의 대응 디렉터리와 통합하는 파일 시스템 배치가 필수가 되었다. Daedalus에서 Excalibur로 업그레이드하거나 Debian Trixie에서 마이그레이션할 때는 먼저 usrmerge 구성을 완료해야 하며, 공식 문서는 이 단계를 생략하지 않도록 안내한다.^[49][50]

이 변화는 init 선택과 별개의 Debian 계통 파일 시스템 전환이다. Devuan이 systemd를 사용하지 않는다고 해서 Debian 기반의 다른 구조 변화까지 모두 거부하는 것은 아니며, 패키지 호환성과 유지 관리를 위해 기반 배포판의 변화를 선택적으로 수용한다는 사례다.

SysVinit

SysVinit은 Devuan의 기본 init 시스템이다. 전통적인 System V 방식의 런레벨, /etc/inittab, /etc/init.d 서비스 스크립트와 update-rc.d 계통 도구를 사용한다. 설정이 파일과 셸 스크립트로 명시되어 있어 기존 Debian 및 UNIX 계열 관리 경험을 적용하기 쉽고, Devuan이 제공하는 가장 널리 시험된 기본 경로다.^[51]

SysVinit 구성에서는 시작 순서와 의존 관계가 init 스크립트 메타데이터 및 런레벨 링크로 표현된다. 서비스 감독과 자동 재시작은 별도의 도구나 각 데몬의 기능에 맡기는 경우가 많다. 단순성과 기존 호환성이 강점인 반면, 장기 실행 프로세스를 지속적으로 감독하는 기능은 runit 같은 감독 중심 시스템과 설계 초점이 다르다.

OpenRC

OpenRC는 서비스 사이의 의존 관계와 런레벨을 관리하는 init·서비스 관리 프레임워크다. Devuan에서는 ASCII부터 공식적으로 사용할 수 있으며, 시스템의 PID 1 구현과 조합하거나 OpenRC 중심으로 서비스를 관리할 수 있다. 병렬 시작, 의존성 표현, 서비스 상태 관리와 기존 init 스크립트와의 공존을 중시하는 사용자에게 선택지가 된다.^[52][53]

runit

runit은 프로세스 감독을 중심에 둔 init 체계로, 각 서비스를 별도 감독 프로세스 아래 실행하고 예상치 못한 종료 뒤 재시작하는 구성을 만들기 쉽다. Devuan에서는 Beowulf부터 공식 제공되었고, 현재 설치기에서도 선택할 수 있다. 단순한 단계로 나뉜 부팅과 서비스 디렉터리 기반 관리는 서버 및 최소 시스템에서 특히 활용된다.^[54][55]

선택과 전환

새 설치에서는 설치기의 init 선택 단계에서 SysVinit, OpenRC 또는 runit을 고를 수 있다. SysVinit이 기본값이고, 다른 init은 사용자가 명시적으로 선택한다. 설치 후 전환도 패키지 수준에서 가능하지만 서비스 스크립트와 활성화 상태가 달라질 수 있으므로 새 설치 때 선택하는 것보다 추가 검증이 필요하다.^[56]

Devuan 공식 문서는 sinit, s6와 GNU Shepherd 같은 다른 init도 후보 또는 관심 대상으로 언급하지만, Excalibur에서 설치기와 공식 기본 경로가 직접 제공하는 선택은 SysVinit, OpenRC와 runit이다. 따라서 “Devuan은 어떤 init이든 동일한 수준으로 지원한다”기보다 세 가지 주 경로를 안정적으로 제공하고 다른 구현의 가능성도 열어 둔 것으로 이해하는 편이 정확하다.^[57]

APT와 dpkg

Devuan은 Debian과 마찬가지로 저수준 패키지 설치·제거와 데이터베이스 관리를 dpkg가 맡고, 저장소 검색·의존성 해결·업그레이드는 APT가 담당한다. 패키지 형식도 deb이므로 일반적인 apt, apt-get, apt-cache, dpkg, apt-file과 reportbug 계통 사용법을 대부분 그대로 적용할 수 있다.^[58]

Devuan 고유의 차이는 APT가 바라보는 저장소와 일부 패키지의 공급 주체다. 사용자는 Debian 저장소가 아니라 Devuan의 merged 저장소를 등록하고, APT가 Debian에서 재사용되는 패키지와 Devuan 포크 패키지를 적절한 우선순위로 받도록 해야 한다.

릴리스 이름과 suite

/etc/apt/sources.list에는 stable, testing 같은 suite 이름이나 excalibur, freia 같은 코드명을 사용할 수 있다. suite 이름은 새 안정판이 공개될 때 가리키는 릴리스가 바뀌므로 자동으로 다음 세대로 이동할 수 있다. 코드명을 사용하면 관리자가 직접 원본 목록을 바꿀 때까지 같은 릴리스에 남는다.^[59]

Devuan은 서로 다른 릴리스 저장소가 뜻하지 않게 섞이는 일을 줄이기 위해 코드명 사용을 권장한다. Excalibur를 계속 유지하려면 stable보다 excalibur를 사용하고, Freia testing을 추적하려면 freia를 사용한다.

저장소 구성 요소

기본 구성 요소 main은 자유 소프트웨어로 이루어진다. 하드웨어 펌웨어나 라이선스 제한 소프트웨어가 필요하면 non-free-firmware, non-free, contrib를 같은 원본 항목에 추가할 수 있다. contrib의 패키지는 그 자체로 자유 소프트웨어일 수 있지만 실행 또는 빌드에 비자유 구성 요소를 요구할 수 있다.^[60]

안정판에는 기본 릴리스 저장소와 보안 업데이트 저장소가 있으며, 필요에 따라 일반 업데이트, proposed-updates와 backports를 사용할 수 있다. proposed-updates는 다음 포인트 릴리스 후보를 미리 제공하므로 생산 환경에서의 광범위한 사용보다 시험 목적에 맞고, backports는 testing의 더 새로운 소프트웨어를 안정판 의존성에 맞춰 제공하므로 필요한 패키지에 한정해 활성화하는 방식이 권장된다. experimental은 매우 새로운 패키지 시험용이다.^[61]

미러와 서명

기본 패키지 진입점은 deb.devuan.org이며, DNS와 미러 네트워크를 통해 실제 저장소 서버로 연결된다. 지역 코드가 붙은 주소나 특정 미러를 직접 선택할 수도 있다. 과거의 auto.mirror.devuan.org는 폐기되었으므로 최신 구성에서는 사용하지 않는다.^[62]

저장소 메타데이터는 OpenPGP로 서명되며 신뢰 키는 devuan-keyring 패키지로 배포된다. ISO와 설치 이미지도 SHA-256 체크섬 및 담당 개발자의 OpenPGP 서명으로 검증할 수 있다. Tor 전송을 위한 APT 저장소 접근도 공식적으로 제공된다.^[63][64]

디버깅 패키지

Devuan 전용 및 포크 패키지의 디버깅 심볼은 같은 저장소에서 -dbgsym 또는 -dbg 패키지로 제공된다. 별도 포크 없이 Debian 패키지를 그대로 사용하는 경우에는 Debian debug 저장소나 debuginfod 서비스를 함께 활용할 수 있다. 이는 일반 패키지 저장소를 Debian과 섞는 것과 달리, 디버깅 심볼을 위한 공식 안내된 보조 경로다.^[65]

설치 매체

Devuan Excalibur는 용도별로 여러 설치 매체를 제공한다. netinstall은 핵심 구성만 이미지에 포함하고 나머지를 네트워크에서 내려받아 최소 서버나 선택형 데스크톱을 구성한다. 다섯 장으로 나뉜 server CD 세트는 네트워크가 없는 환경에서 서버 및 제한된 데스크톱 패키지를 설치할 수 있게 하며, desktop DVD는 KDE Plasma와 LXQt를 포함한 여러 데스크톱 선택지를 오프라인으로 제공한다.^[66]

desktop-live는 설치 전에 기본 Xfce 환경을 실행해 보고 Refracta Installer로 디스크에 설치할 수 있는 라이브 이미지다. minimal-live는 콘솔 중심 복구 환경으로, 시각 장애 사용자를 위한 접근성에 중점을 두고 Refracta Installer도 포함한다. 이 밖에 작은 netboot·mini ISO, PXE 설치 파일과 아키텍처별 설치기 이미지가 제공된다.^[67]

표준 설치기

amd64용 일반 설치기는 Debian Installer 계통의 텍스트·프레임버퍼 인터페이스를 사용한다. 언어, 키보드, 네트워크, 사용자, 파티션, 미러, 소프트웨어 모음, 부트로더와 init 시스템을 단계별로 선택한다. Excalibur에서는 설치기 이미지 크기 제약으로 d-i의 그래픽 프런트엔드가 제공되지 않지만, desktop-live의 Refracta Installer는 그래픽 설치 경로를 제공한다.^[68][69]

설치기의 기본 데스크톱은 Xfce이며, 매체와 네트워크 상태에 따라 Cinnamon, KDE Plasma, LXQt, LXDE, MATE 또는 최소 시스템을 선택할 수 있다. init 선택 화면에서는 SysVinit이 기본이고 OpenRC와 runit을 선택할 수 있다. 서버는 데스크톱 작업을 선택하지 않고 SSH 서버와 표준 시스템 유틸리티만 설치하는 방식으로 구성할 수 있다.^[70][71]

파티션과 암호화

일반적인 자동 파티션, LVM, 수동 파티션과 UEFI·BIOS 부팅 구성을 사용할 수 있다. 공식 문서는 LUKS와 LVM을 조합해 부팅에 필요한 영역을 제외한 시스템을 암호화하는 전체 디스크 암호화 절차도 제공한다. 라이브 설치기에서도 BIOS와 UEFI, 일반 파티션과 암호화 설치를 지원한다.^[72][73]

펌웨어

모든 설치 매체에는 필요한 경우 설치할 수 있는 비자유 펌웨어 패키지가 들어 있다. 일반 설치는 감지된 Wi-Fi 등 하드웨어에 필요한 펌웨어를 설치할 수 있으며, 비자유 펌웨어의 자동 설치를 피하려면 expert install을 선택한다. desktop-live와 minimal-live에는 넓은 하드웨어 부팅을 위해 비자유 펌웨어가 미리 포함되어 있고, 부팅 뒤 /root/remove_firmware.sh로 제거할 수 있다.^[74]

이미지 검증

공식 이미지와 체크섬 파일을 같은 미러에서 받아 SHA-256 해시를 비교하고, 서명 파일을 Devuan 개발자 키로 검증할 수 있다. 단순한 해시 비교는 전송 오류를 찾고, OpenPGP 서명은 체크섬이 공식 빌드 담당자에게서 왔는지 확인한다. 설치 매체를 만들기 전에 두 검증을 함께 수행하는 것이 권장된다.^[75][76]

Daedalus에서 Excalibur로

Devuan은 연속된 안정판 사이의 업그레이드 경로를 문서화하며, 중간 릴리스를 건너뛰는 업그레이드는 지원하지 않는다. Daedalus에서 Excalibur로 옮길 때는 먼저 현재 시스템을 완전히 업데이트하고 백업한 뒤 usrmerge를 설치해 병합된 /usr 구성을 완료한다. 그 다음 APT 원본의 코드명을 daedalus에서 excalibur로 변경하고 일반 업그레이드와 전체 의존성 전환을 순서대로 수행한다.^[77]

업그레이드 전에는 보류 패키지, 제3자 저장소, 로컬 패키지와 디스크 여유 공간을 확인해야 한다. 재부팅 뒤 사용하지 않는 패키지와 이전 커널을 정리할 수 있지만, 원격 서버에서는 init·네트워크·SSH가 새 환경에서 정상적으로 올라오는지 확인할 복구 경로를 준비하는 편이 적합하다.

Debian Trixie에서 Excalibur로

Debian 13 Trixie에서 Devuan 6 Excalibur로 마이그레이션하는 공식 경로도 제공된다. 절차는 병합된 /usr 상태를 확인하고 Debian 원본을 Devuan Excalibur 원본으로 교체한 뒤 devuan-keyring을 설치하고 패키지 목록과 기본 패키지를 갱신하는 방식으로 시작한다. 이후 eudev와 선택한 init 패키지를 설치해 systemd-sysv를 교체하고 재부팅한 다음, 세션 관리와 나머지 배포판 업그레이드를 마무리한다.^[78]

공식 절차가 단계를 나누는 이유는 저장소, PID 1, 장치 관리자와 데스크톱 세션을 한 번에 무질서하게 바꾸지 않기 위해서다. 특히 그래픽 데스크톱 패키지가 eudev 전환 과정에서 일시적으로 제거될 수 있으므로, 재부팅 뒤 적절한 세션 관리 패키지와 데스크톱 작업을 다시 설치하도록 안내한다.^[79]

코드명 고정과 릴리스 전환

업그레이드 시점과 무관하게 sources.list에서 suite 이름을 사용하면 새 릴리스 공개와 함께 대상이 바뀔 수 있다. 운영자가 계획된 유지 보수 창에만 업그레이드하려면 코드명을 고정하고, 공식 업그레이드 문서를 읽은 뒤 다음 코드명으로 직접 바꾸는 방식이 적합하다. testing을 추적하는 사용자는 freia처럼 코드명을 사용해 해당 개발 계열이 안정판으로 승격될 때 자연스럽게 같은 릴리스에 남을 수 있다.^[80]

Xfce

Xfce는 Devuan의 기본 데스크톱 환경이다. 비교적 가볍고 전통적인 패널·메뉴·창 관리 구조를 제공하며, systemd를 PID 1로 요구하지 않는 구성이 오래 검증되어 기본 라이브 이미지와 일반 데스크톱 설치의 기준이 된다.^[81]

다른 데스크톱 환경

공식 설치 선택지에는 Cinnamon, KDE Plasma, LXQt, LXDE와 MATE가 포함되며, 매체에 없는 환경도 설치 후 저장소에서 추가할 수 있다. desktop DVD는 네트워크 없이 여러 환경을 설치할 수 있도록 더 많은 패키지를 포함하고, netinstall은 네트워크에서 선택한 작업을 내려받는다.^[82][83]

데스크톱 환경 자체가 systemd를 PID 1로 실행하지 않더라도 일부 구성 요소는 logind 계통 인터페이스, D-Bus, PolicyKit, 좌석 관리와 전원 관리 기능을 기대할 수 있다. Devuan은 elogind, libseat와 패키지 패치를 이용해 이러한 기능을 제공한다. 환경별 의존성 차이 때문에 기본 Xfce 경로가 가장 단순하고, 다른 환경은 릴리스별 패키지 상태를 확인하는 편이 좋다.

X11과 Wayland

X11 데스크톱은 전통적으로 startx나 디스플레이 관리자를 통해 시작할 수 있다. Daedalus에서는 libseat를 이용해 루트 권한 없이 startx를 실행하고, 일부 Wayland 그래픽 인터페이스를 elogind 없이 동작시키는 구성이 추가로 강조되었다. Excalibur에서도 데스크톱 환경과 compositor가 지원하는 범위에서 X11과 Wayland를 사용할 수 있다.^[84]

오디오와 멀티미디어

Excalibur 릴리스 노트는 일반 데스크톱 오디오에 PipeWire 사용을 제안하며, PulseAudio 호환 계층과 세션 관리기를 함께 구성할 수 있다. 다만 화면 읽기 프로그램을 사용하는 그래픽 로그인과 같은 접근성 구성은 PulseAudio가 더 적합할 수 있다고 안내한다. 사용자는 데스크톱 환경과 접근성 요구에 따라 오디오 스택을 선택할 수 있다.^[85]

접근성

minimal-live는 시각 장애 및 저시력 사용자를 위한 콘솔 복구 환경에 중점을 둔다. Chimaera부터 설치기의 음성 합성과 점자 디스플레이 지원이 강화되었으며, 데스크톱에서도 Orca 계통 화면 읽기 프로그램과 접근성 패키지를 사용할 수 있다.^[86][87]

공식 아키텍처

Excalibur의 일반 운영체제 개요는 amd64, arm64, armel, armhf와 ppc64el을 주요 지원 아키텍처로 제시한다. 릴리스 노트의 패키지 아키텍처 목록에는 riscv64와 i386도 포함된다. 다만 모든 아키텍처에 같은 종류의 설치 ISO와 커널 패키지가 제공되는 것은 아니므로, “패키지 아카이브에 존재함”과 “일반 PC용 완전한 설치 매체가 있음”을 구분해야 한다.^[88][89]

amd64

amd64는 Devuan의 대표적인 데스크톱·노트북·서버 아키텍처다. desktop-live, netinstall, server CD, desktop DVD와 minimal-live 등 가장 다양한 공식 이미지가 제공되며 BIOS와 UEFI 설치를 모두 지원한다.^[90]

ARM 계열

arm64, armel과 armhf에는 netboot 및 설치기 파일이 제공되며, 보드별 부트로더와 장치 트리가 필요한 단일 보드 컴퓨터용 이미지는 커뮤니티가 별도로 제공한다. ARM 장치는 같은 명령어 집합 이름을 사용해도 부팅 펌웨어와 하드웨어 구성이 크게 다르므로, 대상 보드에 맞는 이미지와 문서를 확인해야 한다.^[91]

ppc64el과 riscv64

ppc64el은 Beowulf부터 주요 지원 아키텍처에 포함되었고 Excalibur에서도 설치기·패키지 대상이다. riscv64는 Excalibur 릴리스 아키텍처에 포함되어 패키지와 특수 설치 매체를 제공하지만, amd64와 같은 모든 데스크톱 라이브 이미지가 제공된다는 뜻은 아니다.^[92][93]

i386

Excalibur 저장소에는 i386 패키지가 남아 있어 일부 32비트 사용자 공간과 멀티아치 용도로 사용할 수 있지만, 공식 릴리스 노트는 i386용 linux-image와 설치 ISO를 제공하지 않는다고 명시한다. 따라서 32비트 x86 컴퓨터에 Excalibur를 새로 설치하는 일반 경로보다 amd64 시스템에서 필요한 32비트 라이브러리를 사용하는 제한적 지원에 가깝다.^[94]

펌웨어와 드라이버

커널 드라이버 지원은 대체로 기반 Debian 릴리스와 Linux 커널 버전을 따른다. 자유 펌웨어만으로 동작하지 않는 무선 네트워크, 그래픽과 기타 장치는 non-free-firmware가 필요할 수 있다. 설치 매체는 이러한 펌웨어를 포함하지만 expert install로 설치를 거부하거나 라이브 시스템에서 제거할 수 있어, 하드웨어 호환성과 자유 소프트웨어 정책 사이에서 사용자가 선택할 수 있다.^[95]

가상 머신

Devuan은 일반 Linux 게스트로 QEMU/KVM, VirtualBox, VMware와 다른 하이퍼바이저에서 실행할 수 있다. 최소 netinstall을 이용해 작은 서버 게스트를 만들거나 Devuan SDK의 vm-sdk로 반복 가능한 가상 머신 이미지를 빌드할 수 있다. init이 가볍고 사용자 공간 구성이 Debian과 유사해 테스트·서비스 격리·레거시 환경 재현에 활용된다.^[96]

컨테이너 이미지

Excalibur 릴리스 노트는 공식 Docker Hub 이미지 devuan/devuan:excalibur를 제공한다고 안내한다. 컨테이너에서는 일반적으로 호스트 커널을 공유하고 PID 1 구성이 전체 시스템과 다르므로, Devuan 컨테이너 이미지는 완전한 부팅형 가상 머신보다 Devuan 사용자 공간과 패키지 저장소를 재현하는 기반 이미지로 쓰인다.^[97]

임베디드와 단일 보드 컴퓨터

Devuan은 초기 릴리스부터 ARM 장치와 임베디드 시스템을 주요 활용 대상으로 다뤘다. 현재 보드별 이미지는 공식 릴리스 ISO와 별도로 커뮤니티가 관리하며, Devuan SDK의 arm-sdk는 커널·부트로더·루트 파일 시스템을 조합한 장치 이미지를 만드는 데 사용된다.^[98][99]

네트워크 부팅

아키텍처별 Debian Installer 계통 파일과 PXE netboot 이미지를 사용해 다수의 서버나 디스크 없는 환경을 네트워크에서 부팅하고 설치할 수 있다. 이 방식은 설치 이미지에 모든 패키지를 포함하지 않고 중앙 미러와 자동 설치 구성을 활용하기 때문에 데이터센터 및 실험실 배포에 적합하다.^[100]

Devuan 릴리스 코드명은 소행성체센터의 이름 목록에서 고른다. 첫 안정판 Jessie는 기반 Debian과 같은 이름을 사용했으며, 이후 ASCII, Beowulf, Chimaera, Daedalus, Excalibur, Freia, Gryphon처럼 A부터 알파벳 순서로 이어진다. unstable은 소행성 번호 1번 Ceres의 이름을 고정적으로 사용하며 Debian의 Sid에 대응한다.^[101]

릴리스의 상태와 날짜, 기반 Debian 및 소행성 번호는 공식 릴리스 정보에서 관리된다. 보관된 릴리스는 동결되어 기능·일반 업데이트·보안 업데이트를 더 이상 받지 않으며 전용 archive 저장소로 이동한다.^[102]

Jessie 1

Jessie는 Devuan이 Debian 포크 선언 뒤 완성한 첫 안정판이자 첫 장기 지원 기반이었다. SysVinit을 기본으로 Debian Jessie의 사용자 공간과 호환성을 유지하고, 설치 ISO, 라이브·최소·임베디드 이미지, 자체 저장소와 버그 추적 체계를 처음으로 하나의 안정판에 모았다.^[103]

ASCII 2

ASCII는 eudev와 elogind를 본격적으로 채택하고 OpenRC를 공식 선택지로 제공했으며, 새 미러 네트워크와 다양한 데스크톱·ARM 설치 경로를 정비했다. 2.1 포인트 릴리스에서는 보안 업데이트와 설치 선택 화면이 개선되고 ARM 및 가상 머신 이미지가 커뮤니티 제공 체계로 이동했다.^[104][105]

Beowulf 3

Beowulf는 runit을 추가해 공식 init 선택을 세 가지로 넓히고 ppc64el 지원을 포함했다. 3.1 포인트 릴리스에서는 설치기에서 SysVinit, OpenRC와 runit 선택을 더 명확하게 제공했다.^[106][107]

Chimaera 4

Chimaera는 Debian Bullseye 세대의 패키지와 Linux 5.10을 가져오면서 세 init 경로를 유지했다. 여러 데스크톱 환경을 systemd PID 1 없이 사용할 수 있도록 패키지를 정비하고, 설치 접근성과 PulseAudio를 사용하지 않는 선택지를 개선했다.^[108]

Daedalus 5

Daedalus는 Debian Bookworm 세대로 이동했으며, 그래픽 좌석 관리에 libseat를 활용해 루트 없는 X 세션과 일부 elogind 비의존 Wayland 구성을 지원했다. 이 릴리스는 Excalibur로 직접 업그레이드할 수 있는 이전 안정판이다.^[109]

Excalibur 6

Excalibur는 Debian Trixie 세대와 Linux 6.12를 기반으로 하며 merged-usr를 필수화했다. 현재 공식 설치 매체, 미러, 패키지 저장소, Docker 이미지, Daedalus 업그레이드와 Debian Trixie 마이그레이션 문서의 기준 릴리스다. /run/utmp 지원 복원, 최신 데스크톱·오디오 구성과 아키텍처별 설치 파일도 릴리스 노트에 정리되어 있다.^[110]

Freia와 Ceres

Freia는 Devuan 7이 될 testing 릴리스로 Debian Forky를 기반으로 개발되고 있다. 저장소는 이미 공개되어 있으나 안정판으로 발표되지 않았으며, 생산 환경보다 시험과 패키지 검증에 적합하다. Ceres는 고정 버전 번호 없이 계속 변하는 unstable 계열로, 최신 패키지를 Devuan 환경에 통합하고 다음 testing 후보를 준비하는 공간이다.^[111][112]

지원 주기와 보관

Devuan은 각 릴리스에 고정된 동일 기간의 상업적 지원 계약을 선언하기보다 stable, oldstable, oldoldstable과 archived 상태로 관리한다. 유지 상태인 릴리스는 저장소와 보안 업데이트를 받을 수 있고, EOL 뒤 archived가 되면 동결되어 추가 업데이트를 받지 않는다. 2026년 10월 현재 Excalibur, Daedalus와 Chimaera가 유지 상태이며 Beowulf 이전은 보관 상태다.^[113]

Devuan SDK

Devuan SDK는 설치 이미지와 파생 시스템을 만드는 반자동 스크립트 모음이다. 공통 기능을 제공하는 libdevuansdk 위에 ARM 이미지용 arm-sdk, 가상 머신용 vm-sdk, 라이브 시스템용 live-sdk 등을 조합하며, Zsh 기반의 모듈식 구조를 사용한다.^[114]

SDK는 Debian 소스 가져오기, Devuan 변경 단계 적용, 루트 파일 시스템 구성, 커널과 부트로더 결합, 라이브·VM·임베디드 이미지 제작을 반복 가능한 방식으로 수행하는 데 쓰인다. 사용자는 공식 이미지와 동일한 목적뿐 아니라 자체 패키지 목록, 설정과 브랜딩을 가진 파생 배포판을 만들 수 있다.

Refracta 도구

Refracta Installer는 실행 중인 라이브 시스템을 디스크에 설치하는 데 사용되고, Refracta Snapshot 계통 도구는 현재 시스템을 바탕으로 새 라이브 이미지를 만드는 데 활용된다. Devuan은 첫 안정판부터 이 도구를 포함해 사용자가 설치된 환경을 재구성하고 자체 라이브 배포판을 만드는 경로를 제공했다.^[115][116]

파생 배포판

Devuan 공식 사이트는 Devuan을 기반 운영체제로 사용하는 여러 파생 배포판을 소개한다. Refracta는 라이브·설치 도구와 가벼운 데스크톱을 제공하고, Gnuinos는 자유 소프트웨어 중심 구성을 지향하며, Star, Crowz, MIYO, EterTICs, Maemo Leste, Peppermint OS Devuan 등은 데스크톱·멀티미디어·모바일·저사양 시스템처럼 서로 다른 용도를 다룬다.^[117]

공식 목록은 Devuan 프로젝트가 직접 모든 파생판을 유지한다는 뜻이 아니다. 각 배포판은 자체 개발자, 릴리스 주기와 지원 범위를 가지며, 일부는 특정 과거 Devuan 릴리스에만 기반하거나 개발이 중단될 수 있다. Devuan은 이 생태계에 공통 패키지 기반과 init 선택권, 이미지 제작 도구를 제공한다.

개발 팀

Devuan은 단일 기업 제품이 아니라 개발자와 기여자 공동체가 유지하는 프로젝트다. 2014년 Veteran Unix Admins가 시작했고 초기 핵심 개발에는 Franco Lanza, Denis Roio와 Daniel Reurich 등이 참여했다. 시간이 지나며 패키징, 인프라, ARM, 문서, 웹사이트, 미러와 커뮤니티 운영을 담당하는 기여자들이 합류했다.^[118]

Dyne.org 재단은 초기부터 재정 및 행정 지원을 제공했고 Devuan 상표를 보유한다. 프로젝트 개발은 공개 Git 저장소, 메일링 리스트, IRC, 포럼과 버그 추적 시스템을 중심으로 이루어진다.

소통 채널

일반 사용자 지원과 개발 논의는 Libera.Chat의 #devuan, #devuan-dev, #devuan-arm 등의 IRC 채널, DNG 메일링 리스트, 개발 메일링 리스트와 Dev1Galaxy 포럼에서 이루어진다. 공지는 별도 저빈도 메일링 리스트로 배포되며, 언어별 또는 문서 편집 채널도 운영된다.^[119]

버그 추적과 기여

Devuan BTS는 Debian의 debbugs 계통을 사용하며 reportbug 도구나 웹·전자우편을 통해 문제를 제출할 수 있다. 기여자는 먼저 문제가 Debian 원본 패키지인지 Devuan 포크 및 통합 문제인지 구분하고, 재현 정보와 설치한 init, 릴리스, 아키텍처를 함께 제시하는 것이 좋다.^[120]

패키지와 인프라 개발은 Git 저장소와 Jenkins에서 진행되고, 문서·번역·미러 운영·테스트·포럼 지원도 중요한 기여 영역이다. Devuan은 testing과 unstable 사용자의 패키지 검증을 다음 안정판 품질을 높이는 과정으로 본다.^[121]

서버

Devuan은 Debian식 안정판 패키지와 익숙한 APT 운영 모델을 유지하면서 init 구성을 직접 통제하고 싶은 서버에 사용할 수 있다. 최소 netinstall, 오프라인 server CD, SSH 작업 선택, runit의 서비스 감독이나 SysVinit의 전통적인 스크립트를 목적에 맞게 조합할 수 있다. 다만 원격 업그레이드에서는 부팅·네트워크·SSH 서비스의 init 설정을 사전에 확인해야 한다.

데스크톱과 워크스테이션

Xfce 기본 환경은 비교적 적은 자원으로 전통적인 데스크톱을 제공하고, KDE Plasma·Cinnamon·MATE·LXQt·LXDE 등으로 확장할 수 있다. Debian 계통 응용 프로그램을 폭넓게 사용할 수 있으므로 일반 사무, 개발, 멀티미디어와 교육용 워크스테이션으로 구성할 수 있다.^[122]

개발 및 시험 환경

Debian 호환 패키지를 사용하면서 systemd가 없는 환경에서 소프트웨어를 시험해야 할 때 Devuan은 재현 가능한 대상이 된다. 서비스가 SysVinit, OpenRC와 runit에서 올바르게 시작되는지, 패키지가 systemd에 불필요하게 의존하는지, 데몬이 독립적인 로그·권한·종료 처리를 제공하는지 확인할 수 있다.

복구 시스템

minimal-live는 콘솔 복구 도구와 접근성을 중심으로 설계되어 파일 시스템 복구, 부트로더 수정, 데이터 백업과 다른 Linux 설치의 진단에 사용할 수 있다. desktop-live는 그래픽 환경에서 하드웨어 호환성을 시험한 뒤 설치하거나, 네트워크와 브라우저를 포함한 임시 작업 환경으로 사용할 수 있다.^[123]

파생 배포판과 전용 장치

Devuan SDK와 Refracta 도구를 사용하면 기관용 라이브 시스템, 키오스크, 저사양 데스크톱, 연구 장비, ARM 장치와 특정 응용 프로그램에 맞춘 이미지를 만들 수 있다. Debian 패키지 생태계를 재사용하면서 init과 기본 서비스 구성을 작게 통제하려는 프로젝트에 적합하다.^[124]

Devuan의 가장 뚜렷한 특징은 Debian 생태계와 init 선택권을 결합한다는 점이다. 사용자는 APT와 Debian식 관리 방식을 유지하면서 SysVinit, OpenRC 또는 runit을 고를 수 있고, eudev·elogind·libseat 같은 분리된 구성 요소로 장치 및 세션 기능을 구성할 수 있다. 서버, 데스크톱, 라이브 이미지와 파생 배포판을 같은 패키지 기반에서 다룰 수 있다는 점도 범용 기반 배포판으로서의 강점이다.

운용 방식은 Debian과 매우 비슷하지만 완전히 같지는 않다. 저장소를 Debian과 직접 섞지 않아야 하고, 기반 Debian과 Devuan의 출시 시점이 다르며, systemd에 강하게 결합된 소프트웨어는 Devuan 패치나 대체 구성 요소가 준비될 때까지 차이가 생길 수 있다. 패키지 문제를 조사할 때도 Debian 원본 문제와 Devuan 고유 통합 문제를 구분해야 한다.^[125][126]

init 선택에 따라 문서와 운영 절차도 달라진다. Debian이나 다른 배포판의 systemctl 지침을 그대로 적용하는 대신 선택한 init의 서비스 명령, 런레벨 또는 서비스 디렉터리를 사용해야 한다. 세 init 모두 공식 선택지지만 패키지별 사용량과 시험 범위는 같지 않으므로, 가장 널리 검증된 기본 경로가 필요하면 SysVinit을 사용하고 감독·의존성 관리 요구에 따라 OpenRC나 runit을 선택할 수 있다.

아키텍처와 설치 매체의 지원 범위도 구분해야 한다. amd64는 모든 주요 ISO를 제공하지만 i386은 Excalibur에서 커널과 설치 ISO가 없고, ARM과 riscv64는 보드별 부팅 이미지나 netboot를 확인해야 한다. 비자유 펌웨어는 설치 편의를 위해 매체에 포함될 수 있으므로 자유 소프트웨어만으로 구성하려는 사용자는 expert install 또는 설치 후 제거 절차를 선택할 수 있다.^[127][128]

업그레이드는 인접한 릴리스 사이의 공식 경로를 따르는 것이 중요하다. 특히 Excalibur는 merged-usr를 요구하므로 Daedalus에서 usrmerge를 먼저 적용해야 하며, Debian Trixie에서 옮길 때는 저장소·키링·장치 관리자·init·세션 관리 전환 순서를 지켜야 한다. 이러한 차이를 반영하면 Devuan은 systemd 비의존 환경을 장기적으로 유지하면서 Debian 계통 소프트웨어를 활용하는 선택지가 된다.^[129][130]

• Debian
• Linux 배포판
• Linux 커널
• systemd
• SysVinit
• OpenRC
• runit
• eudev
• elogind
• APT
• dpkg
• deb
• Xfce
• KDE Plasma
• Cinnamon
• MATE
• LXQt
• LXDE
• PipeWire
• Wayland
• X Window System
• QEMU
• Docker