Debian GNU/Linux FAQ
3 하드웨어 요구사항들

3.1 Debian GNU/Linux Debian GNU/Linux 는 어떤 구조와 시스템에서 동작하는가 ?

Debian GNU/Linux는 포함된 모든 풀그림의 전체 소스를 포함하고 있어서 리눅스 커널에 의해 지원되는 모든 시스템에서 동작한다: 자세한 것은 리눅스 FAQLinux FAQ 를 보라.

현재의 Debian GNU/Linux 배포본, 2.2, 아래와 같은 구조를 위한 완전한 이진 배포본을 가지고 있다:

i386: 이것은 80386, 80486, 펜티엄, 펜티엄 프로, 펜티엄 II (Klamath와 Celeron)과 펜티엄 III와 그리고 AMD, Cyrix 등의 인텔 호환 프로세서들에 기반을 둔 개인용 컴퓨터를 지원한다.

m68k: x >= 2인 MMU를 포함한 Motorola 680x0 프로세서를 사용하는 아미가와 아타리를 지원한다.

alpha: 컴팩/디지탈 알파 시스템

sparc: 이는 선의 스팍과 대부분의 울트라 스팍 대부분을 포함한다.

powerpc: 이는 CHRP, PowerMac과 PReP 기계들을 포함하는 몇몇 IBM/모토롤라 PowerPC를 포함한다.

arm: ARM과 StrongARM 기계들을 포함한다.

스팍64(울트라스팍 native)과 MIPS를 위한 데비안의 이진 배포본의 개발은 현재 진행중이다.

부팅과 하드드라이브의 파티션 PCMCIA (PC 카드)의 작동여부와 같은 문제에 관한 더 많은 정보는 설치 매뉴얼 에 나와있는 지시사항을 따르면 된다. 설치매뉴얼은 다음 사이트에서 볼 수 있다: http://www.debian.org/releases/stable/i386/install.

3.2 데비안과 다른 리눅스 배포본은 어느 정도 호환성이 있나 ?

데비안 개발자들은 리눅스 배포본간의 이진 호환성을 유지하는 노력을 다른 배포본 작성자들과 교환한다. 대부분의 상업적 리눅스 제품은 그것들이 만들어진 시스템에서와 같이 데비안에서도 잘 동작한다.

Debian GNU/Linux는 리눅스 파일 시스템 구조를 엄격히 고수하고 있다. 그러나 이 표준에 속한 몇몇의 규정들을 해석하는 여지가 남아 있어서 데비안과 다른 리눅스 배포본과의 차이가 존재하는 듯하다. FSSTND 표준의 최신판을 FHS 로 부르고 데비안도 곧 옮겨갈 것이다.

3.3 데비안과 다른 유닉스 시스템들과의 소스 호환성은 ?

대부분의 응용풀그림의 리눅스 소스는 다른 유닉스 시스템과 호환된다. 그것은 사용가능한 System V 유닉스 시스템들과 BSD 로 부터 유래한 상업적인것과 비상업적인 것들 거의 대부분을 지원한다. 그러나 유닉스 사업에 있어서 그런 주장은 그것을 증명할 방법이 없기 때문에 거의 가치가 없다. 소프트웨어 개발은 "거의 모든" 경우에 호환성이 있다 보다는 완전한 호환성을 요구한다. 그래서 몇 년 전부터 표준에 대한 요구가 있어왔고 이제는 POSIX.1 (IEEE Standard 1003.1-1990) 이 유닉스 호환 시스템의 소스 호환성의 중요한 표준중의 하나이다.

리눅스는 POSIX.1 을 고수하려 한다. 하지만 POSIX 표준은 돈이 많이 들고 POSIX.1 (그리고 FIPS 151-2) 검증은 정말 비싸다; 이것이 리눅스 개발자들이 완변한 POSIX 호환에서 일하는 것을 어렵게 하고 있다. 검증 비용은 데비안이 확인 절차를 모두 통과 했음에도 공식 적합 검증을 얻는 것을 가망 없게 한다. (확인 절차는 이제 자유롭게 사용가능하다. 그래서 그것은 보다 많은 사람들이 POSIX.1 논쟁에 참여 하게 할 것이다.)

Unifix GmbH (Braunschweig, Germany)는 FIPS 151-2 (POSIX.1의 모음)에 알맞게 된 리눅스 시스템을 개발했다. 이 기술은 Unifix 리눅스 2.0라고 불리는 Unifix자체의 배포본에 포함되어 있고 또한 Lasermoon의 Linux-FT에도 포함되어 있다.

3.4 RedHat/Slackware/... 리눅스 시스템에서 데비안 패키지 (".deb" 파일들) 를 쓸수 있는가 ? Debian GNU/Linux 시스템에서 RedHat 패키지들 (".rpm" 파일들)을 쓸 수 있나 ?

다른 리눅스 배포본들은 다른 패키지 형식과 관리 풀그림을 사용한다.

이런건 아마 할 수 있다:

`다른' 배포본은 데비안 패키지를 파일을 압축파일을 푸는 관점에서 볼때 리눅스 호스트에 풀어 넣을 수 있는 풀그림이 있고 일반적으로 동작할 것이다. 그 반대도 아마 될것이다, Debian GNU/Linux에 기초로한 호스 트에 RedHat 또는 Slackware 패키지를 압축을 풀고 그들이 의도한 디렉토리에 대부분의 파일을 넣을 수 있는 풀그림이 있다. 이것이 리눅스 파일 시스템의 존재 (그리고 광범위한 추종)의 커다란 결과이다.

이런 것은 원하지 않을 것이다:

대부분의 패키지 관리자들은 그들이 사용하는 관리 파일을 작성한다. 이런 관리 파일들은 일반적으로 표준화가 않되어 있다. 그래서 데비안 패키지를 `다른' 호스트에 풀어 넣는 것은 시스템에 있는 패키지 관리자에게 예측할 수 없는 (확실히 유용치 않은)결과를 낳게 될 것이다. 똑같이 다른 배포본의 유틸리티를 데비안 시스템에 풀어 넣는 것이 성공할지라도 판올림이나 패키지 삭제 또는 단지 시스템에 있는 패키지 확인 작업시에 데비안 패키지 관리 시스템에 오류를 발생 시킬 수 있다.

더 좋은 방법:

리눅스 파일 시스템 표준(따라서 Debian GNU/Linux)은 /usr/local/밑의 하위 디렉토리는 전적으로 사용자의 판단에 두도록 요구한다. 따라서 사용자는 `다른' 패키지를 이 디렉토리에 풀어 놓을 수 있고 그것의 설정, 판올림, 삭제를 개별적으로 관리할 수 있다.

3.5 데비안은 오래된 "a.out" 프로그램들을 실행시킬수 있는가 ?

아직도 그런 프로그램 갖고 있나요? :-)

a.out(즉, QMAGIC or ZMAGIC)형태의 이진 프로그램을 실행하려면,

• 커널에 직접 (CONFIG_BINFMT_AOUT=y) 또는 모듈 (CONFIG_BINFMT_AOUT=m)로 a.out을 지원하는 부분을 넣어야 한다. (데비안의 커널 이미지 패키지는 binfmt_aout 모듈을 포함한다.)

  a.out 이진 파일들을 커널에서 모듈로 지원하려면 binfmt_aout 모듈이 적제되도록 해야된다. 이 일은 binfmt_aout줄을 /etc/modules 파일에 넣으면 기동시에 된다. 이건insmod DIRNAME/binfmt_aout.o 을 명령라인에서 실행시켜서도 할수 있는데 여기서 DIRNAME는 현재 커널 버전에 맞도록 만들어진 모듈이 저장된 디렉토리 이름이다. 커널 버전이 2.2.17인 시스템에서는 DIRNAME 은 /lib/modules/2.2.17/fs/와 비슷하다.

• libc4패키지를 설치, 2.0이전의 배포폰에서 발견되는데 (왜냐하면 이 패키지를 지웠기 때문이다.)이런 경우에는 좀 오래된 데비안 시디롬을 찾는게 간편한 방법이다 (데비안 1.3.1은 가지고 있다). 또는 ftp://archive.debian.org/debian-archive/ 이곳을 살펴보면 된다.

• a.out의 X 클라이언트를 실행시키려면, xcompat를 설치하라 (아직 얻을 수 있는지는 위의 내용을 참조하라).

만일a.out상업용 풀그림을 가지고 있다면 지금이 ELF 판올림을 보내달라고 요청할 좋은 때이다.

3.6 데비안은 오래된 libc5 프로그램을 실행 할 수 있나?

그렇다. libc5를 oldlibs에서 찾아서 설치하라. (오래된 응용프로그램과 호환성을 위해 오래된 패키지를 포함하는 oldlibs)

3.7 데비안을 오래된 libc5 프로그램을 컴파일하는데 사용할수 있나?

가능하다. libc5-altdev와 altgcc들을 (oldlibs부분에서) 설치하라. 적절한 libc5로 컴파일된 /usr/i486-linuxlibc1/bin 디렉토리에 있는 gcc 와 g++을 발견할 수 있을 것이다. 경로 $PATH 변수에 이것들을 넣어서 make과 다른 프로그램들이 이 프로그램들을 실행하게 만들면 된다.

만일 libc5 X 클라이언트를 컴파일 해야한다면, xlib6와 xlib6-altdev패키지들을 설치하라.

libc5 환경은 다른 프로그램들이 더이상 지원하지 않는다.

3.8 데비안이 아닌 패키지들을 설치하는 방법은?

/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

어떤 경우에든 패키지의 재배포권이 허용되면 그것을 데비안 패키지로 만드는 것을 고려하라 그리고 데비안 시스템을 위해 올려달라. 패키지 개발자가 되는 지침들은 데비안 정책 설명서(see 데비안 시스템에 있는 다른 문서와 데비안 시스템에 대한 문서는 어떤 것이 있나?, 11.1)에 있다.

3.9 foo를 실행하려고 할 때, "Can't find libX11.so.6"라는 메세지가 나오는데 왜죠?

이 에러메세지는 X11 라이브러리들의 libc5 버젼에 맞지 않는 프로그램들이 링크되어 있음을 의미합니다. 이러한 경우에 oldlibs에서 xlib6 패키지를 설치할 필요가 있다.

여러분이 libXpm.so.4 파일에 해당하는 비슷한 에러메세지를 볼 수 있는데, 이런 경우에 XPM 라이브러리의 libc5 버젼을 설치할 필요가 있는데 이는 oldlibs에 있는 xpm4.7 패키지에 있다.

3.10 libtermcap을 필요로 하는 것은 왜 컴파일 하지 못하나?

데비안은 termcap 데이타베이스와 termcap 라이브러리 대신 terminfo데이타베이스와 ncurses 라이브러리를 사용한다. 터미널 인터페이스에 관한 어떤 지식을 필요로 하는 풀그림을 컴파일 하는 사용자는libtermcap을 참조하는 부분을 libncurses을 참조하도록 바꾸어야 한다.

이미 termcap 라이브러리와 링크되어 있고 소스가 없는 경우에 데비안은 termcap-compat라 부르는 패키지를 제공한다. 이 패키지는 libtermcap.so.2 와 /etc/termcap을 제공한다. "can't load library 'libtermcap.so.2'"의 오류 메시지 또는 /etc/termcap파일이 없다고 불평하고 풀그림의 실행이 중단되면 이 패키지를 설치하라.

3.11 AccelX을 설치할 수 없나 ?

AccelX는 설치에 termcap라이브러리를 사용한다. 위에 있는 libtermcap을 필요로 하는 것은 왜 컴파일 하지 못하나?, 3.10을 참조하라.

3.12 제가 사용하는 오래된 XFree 2.1 모티프 응용프로그램들이 실행이 안되나요?

motifnls 설치하면 XFree-2.1 설정파일을 이용 모티프 응용프로그램을 XFree-3.1에서도 실행되게 XFree-2.1에서 컴파일된 형태로 사용하게 해준다.

이러한 파일들이 없이는 다른 머신에서 컴파일된 몇몇 모티프 응용프로그램들 (예를 들어 네스케이프) 이 텍스트 입력부분에서 복사하고 붙이는 과정에서 실행이 안되고 다른 문제들을 만들어 낼 수 있습니다.