4장. 호환성 이슈

# 4장. 호환성 이슈

## 4.1. 무슨 하드웨어 아키텍처/시스템에서 Debian GNU/Linux 가 돌아가나요?

Debian GNU/Linux에는 모든 프로그램에 완전한 소스코드가 들어가므로, 리눅스 커널이 지원하는 모든 시스템에서 동작해야 합니다. Linux FAQ 참조.

현재 Debian GNU/Linux 릴리스, 13, 완전한 바이너리 배포판이 들어있는 아키텍처:

- amd64: AMD64 확장이 들어간 AMD 64비트 CPU 및 EM64T 확장이 들어간 모든 인텔 CPU 기반 시스템과 공통 64비트 사용자 공간(userspace)을 다룹니다.

- arm64: 최신 64비트 ARM 프로세서 기반 장치를 지원합니다.

- armel: 리틀 엔디안 ARM 머신.

- armhf: 하드웨어 부동소수점(hard-float) 연산을 지원하는 ARMv7 기기용 armel의 대안.

- i386: 인텔 386, 486, 펜티엄, 펜티엄 프로, 펜티엄 II(Klamath 및 Celeron 모두 포함), 펜티엄 III를 포함한 인텔 및 호환 프로세서 기반 시스템과 AMD, Cyrix 등에서 제조한 대부분의 호환 프로세서를 다룹니다.

- ia64: 인텔 IA-64 ("Itanium") 컴퓨터.

- mips: SGI 빅 엔디안 MIPS 시스템, Indy 및 Indigo2; mipsel: 리틀 엔디안 MIPS 머신, 디지털 덱스테이션.

- powerpc: Apple Macintosh PowerMac 모델과 CHRP 및 PReP 개방형 아키텍처 머신을 포함한 일부 IBM/Motorola PowerPC 머신을 다룹니다.

- ppc64el: 64비트 리틀 엔디안 PowerPC 포트, 다양한 최근 PowerPC/POWER 프로세서 지원.

- s390x: 64비트 포트 IBM System z 머신용, s390을 대체.

hurd-i386(i386 32비트 PC용 GNU Hurd 커널), mipsel64(리틀 엔디안 방식 64비트 MIPS), powerpcspe("Signal Processing Engine" 하드웨어용 포트), sparc64(64비트 SPARC 프로세서), sh(Hitachi SuperH 프로세서), 그리고 x32(32비트 포인터를 사용하는 amd64/x86_64 CPU)용데비안 바이너리 배포판 개발이 현재 진행 중입니다.

m68k 아키텍처에 대한 지원은 데비안 릴리스 관리자가 설정한 기준을 충족하지 못하여 Etch(데비안 4.0) 릴리스에서 중단되었습니다. 이 아키텍처는 MMU를 갖춘 Motorola 680x0(x는 2 이상) 프로세서를 탑재한 Amiga 및 ATARI 기기들을 다룹니다. 하지만 이 포트는 현재 공식 stable 버전의 일부는 아닐지라도 여전히 활성화되어 있으며 설치가 가능하므로, 향후 릴리스에서 다시 활성화될 수도 있습니다.

hppa(Hewlett-Packard의 PA-RISC 머신)와 alpha(Compaq/Digital의 Alpha 시스템)에 대한 지원 또한 비슷한 이유로 Squeeze(데비안 6.0) 릴리스에서 중단되었습니다. arm 역시 이 릴리스에서 제외되었는데, 이는 armel 아키텍처로 대체되었기 때문입니다.

32비트 s390 포트(s390)에 대한 지원은 중단되고, Jessie(데비안 8)에서 s390x로 대체되었습니다. 또한, 불충분한 개발자 지원으로 인해 IA-64 및 Sparc용 포트도 이번 릴리스에서 제거되었습니다.

포트에 대한 더 자세한 내용은 웹사이트 포트 페이지 보십시오.

부팅, 드라이브 파티션 설정, PCMCIA(PC 카드) 장치 활성화 및 이와 비슷한 문제에 관한 더 자세한 정보는 설치 매뉴얼에 있는 지침을 따르십시오. 해당 매뉴얼은 웹사이트 https://www.debian.org/releases/stable/installmanual에 있습니다.

## 4.2. 무슨 커널이 Debian GNU/Linux에서 돌아가나요?

리눅스 외에 데비안은 다음 운영 체제 커널용 완전한 바이너리 배포판을 제공합니다:

- FreeBSD: 각각 64비트 PC와 32비트 PC를 위한 kfreebsd-amd64 및 kfreebsd-i386 포트를 통해 제공되었습니다. 이 포트들은 데비안 6.0 Squeeze에서 기술 미리보기(technology preview) 형태로 처음 릴리스되었습니다. 그러나 데비안 8 Jessie 릴리스부터는 포함되지 않았습니다.

이와 더불어, 현재 다음과 같은 adaptation 작업이 진행 중입니다.

- avr32, Atmel의 32비트 RISC 아키텍처용 포트,

- hurd-i386, 32비트 PC용 포트입니다. 이 포트는 GNU 그룹이 개발 중인 새로운 운영체제인 GNU Hurd를 사용합니다.

- sh, Hitachi SuperH 프로세서용 포트.

NetBSD 커널로 배포판을 이식하여 32비트 PC용 netbsd-i386 및 Alpha 머신용 netbsd-alpha를 제공하려는 시도가 있었으나, 이 포트들은 정식으로 릴리스되지 않았으며 현재는 중단되었습니다.

포트에 대한 더 자세한 내용은 웹사이트 포트 페이지 보십시오.

## 4.3. 데비안은 리눅스 다른 배포판과 어떻게 호환가능한가요?

데비안 개발자는 리눅스 배포판에서 바이너리 호환성을 유지하려고 다른 리눅스 배포판 작성자와 소통합니다. [1] 대부분의 상용 리눅스 제품은 빌드된 시스템에서와 마찬가지로 데비안에서도 잘 돌아갑니다.

Debian GNU/Linux 는 리눅스 파일시스템 계층 표준(FHS, Filesystem Hierarchy Standard)을 준수합니다. 하지만 이 표준 내의 일부 규칙에는 해석의 여지가 있기 때문에, 데비안 시스템과 다른 리눅스 시스템 사이에는 약간의 차이가 있을 수 있습니다.

## 4.4. 데비안과 다른 유닉스 시스템은 어떻게 소스 코드 호환이 되나요?

대부분의 응용 프로그램에서 리눅스 소스 코드는 다른 유닉스 시스템과 호환됩니다. 이 제품은 System V Unix 시스템과 무료 및 상용 BSD에서 파생된 시스템에서 사용할 수 있는 거의 모든 것을 지원합니다. 그러나 유닉스 비즈니스에서는 이러한 주장을 입증할 방법이 없기 때문에 거의 아무런 가치가 없습니다. 소프트웨어 개발 영역에서는 "대부분"의 경우 호환성 대신 완전한 호환성이 필요합니다. 수년 전에 표준의 필요성이 대두되었으며, 오늘날 POSIX.1(IEEE 표준 1003.1-1990)은 유닉스 계열 운영체제의 소스 코드 호환성을 위한 주요 표준 중 하나입니다.

리눅스는 POSIX.1을 준수하도록 고안되었지만, POSIX 표준은 실제 비용이 많이 들고 POSIX.1(및 FIPS 151-2) 인증은 비용이 꽤 많이 듭니다. 이로 인해 리눅스 개발자들이 완전한 POSIX 준수를 위해 작업하기가 더 어려워졌습니다. 인증 비용 때문에 데비안이 검증 제품군을 완전히 통과하더라도 공식적인 적합성 인증을 받을 가능성은 거의 없습니다. 이제 검증 제품군을 무료로 사용할 수 있으므로 POSIX.1 문제에 대해 더 많은 사람이 작업할 것으로 예상됩니다.

Unifix GmbH(독일 Braunschweig)는 FIPS 151-2(POSIX.1의 상위 집합) 표준 준수 인증을 받은 리눅스 시스템을 개발했습니다. 이 기술은 Unifix의 자체 배포판인 Unifix Linux 2.0과 Lasermoon의 Linux-FT에서 사용할 수 있었습니다.

## 4.5. 레드햇/슬랙웨어/... 리눅스 시스템에서 데비안 패키지(.deb" 파일)를 사용할 수 있나요? 내 Debian GNU/Linux 시스템에서 레드햇 패키지(.".rpm" 파일)를 사용할 수 있나요?

다른 리눅스 배포판은 다른 패키지 형식과 다른 패키지 관리 프로그램을 씁니다.

할 수 있는 것:

  "외부(foreign)" 배포판을 기반으로 구축된 리눅스 호스트상에서 Debian GNU/Linux 패키지의 압축을 푸는 프로그램은 이미 존재하며, 파일의 압축을 푸는 관점에서는 일반적으로 잘 동작합니다. 그 반대의 경우도 마찬가지입니다. 즉, 데비안 기반의 호스트에서 레드햇이나 슬랙웨어 패키지의 압축을 푸는 프로그램 또한 패키지 압축을 해제하고 대부분의 파일을 의도된 디렉터리에 배치하는 데 아마 성공할 것입니다. 이는 주로 Linux Filesystem Hierarchy Standard가 존재하고, 이를 폭넓게 준수하고 있기 때문에 가능한 결과입니다. Alien 패키지가 서로 다른 패키지 형식을 변환하는데 사용됩니다.

이런 것을 바라지 않을 겁니다:

  대부분의 패키지 관리자는 아카이브의 압축을 풀 때 관리용 파일을 기록합니다. 이러한 관리용 파일들은 일반적으로 표준화되어 있지 않습니다. 따라서 "외부(foreign)" 호스트에서 데비안 패키지의 압축을 푸는 행위는 해당 시스템의 패키지 관리자에 예측할 수 없는(확실히 유용하지는 않은) 영향을 미치게 됩니다. 마찬가지로, 다른 배포판의 유틸리티를 사용하여 데비안 시스템에서 아카이브 압축을 푸는 데 성공할 수는 있겠지만, 이는 추후 패키지를 업그레이드하거나 삭제할 때, 혹은 단순히 시스템에 어떤 패키지들이 있는지 정확히 보고해야 할 때 데비안 패키지 관리 시스템의 오류를 야기할 가능성이 큽니다.

더 좋은 방법:

  리눅스 파일 시스템 표준(따라서 Debian GNU/Linux 역시)은 `/usr/local/` 아래 서브디렉터리는 사용자 재량에 따라야 함을 요구합니다. 따라서 사용자는 "foreign" 패키지를 이 디렉터리에 풀고, 그리고 개별적으로 설정을 관리, 업그레이드 및 제거할 수 있습니다.

## 4.6. 데비안 아닌 프로그램을 어떻게 설치하나요?

`/usr/local/` 디렉터리는 데비안 패키지 관리 시스템 제어 아래 있지 않습니다. 따라서, 당신의 프로그램 소스 코드를 /usr/local/src/ 안에 두는 게 좋습니다. 예를 들어, 패키지 이름 "foo.tar"용 파일을 `/usr/local/src/foo` 디렉터리 안에 추출할 수 있습니다. 컴파일 후 `/usr/local/bin/`에 바이너리를, `/usr/local/lib/`에 라이브러리를, 그리고 `/usr/local/etc/`에 설정파일을 놓으십시오.

프로그램 및 파일을 실제로 다른 디렉터리에 배치해야 하는 경우 여전히 `/usr/local/`에 저장할 수 있으며, 필요한 위치에서 해당 위치로 적절한 심볼릭 링크를 `/usr/local/`에 빌드 할 수 있습니다. 예를 들어 링크를 만들 수 있습니다

    ln -s /usr/local/bin/foo /usr/bin/foo

어쨌든, 저작권이 재배포를 허용하는 패키지를 구했다면, 그 패키지의 데비안 패키지를 만들어 데비안 시스템용으로 업로드하는 것을 고려해야 합니다. 패키지 개발자가 되기 위한 지침은 데비안 정책 매뉴얼(12.1절. “데비안 시스템에 다른 어떤 문서가 있나요?” 참조)에 있습니다.

[1] Linux Standard Base는 여러 배포판에 사용되는 동일한 바이너리 패키지를 허용하기위한 규격입니다.Jessie (데비안 8) 이후 나왔습니다, 데비안은 LSB 호환 추구를 포기했습니다. July 3, 2015 message from Didier Raboud 그리고 배경 정보로 아래 토론을 참조하십시오.

3장. 데비안 배포판 선택 |  | 5장. 데비안 시스템에서 가능한 소프트웨어