"Trans:GentooX86Handbook2-1"의 두 판 사이의 차이
Darkcircle (토론 | 기여) (→빠진 의존성) |
Darkcircle (토론 | 기여) |
||
| 275번째 줄: | 275번째 줄: | ||
==== 시스템 프로파일 보호 ==== | ==== 시스템 프로파일 보호 ==== | ||
| − | {{Example|코드 예제 5.11: 프로파일로 보호하는 | + | {{Example|코드 예제 5.11: 프로파일로 보호하는 꾸러미에 대한 포티지 경고|!!! Trying to unmerge package(s) in system profile. 'sys-apps/portage'<br/> |
!!! This could be damaging to your system. | !!! This could be damaging to your system. | ||
}} | }} | ||
2012년 7월 30일 (월) 05:23 판
포티지 소개
포티지의 세계에 잘 오셨습니다
포티지는 아마도 프로그램 관리에 있어서 가장 주목할만한 혁신 요소가 아닐까 싶습니다. 상당한 유연성과 엄청난 양의 기능들과 함께 리눅스에서 사용할 수 있는 최고의 프로그램 관리 도구로서 자주 볼 수 있는 존재입니다.
포티지는 파이선과 배시로 완전히 작성되었기에 사용자들에게 완전히 두 스크립트 언어로 보일 것입니다.
대부분의 사용자들은 emerge 도구를 통해 포티지로 작업할 것입니다. 이 장의 내용은 emerge man 페이지에서 볼 수 있는 정보를 베꼈음을 의미하지 않습니다. emerge 옵션의 완전한 설명은 man 페이지를 참조하시기 바랍니다.
| 코드 예제 1.1: emerge man 페이지 읽기 |
| $ man emerge |
포티지 트리
Ebuild
꾸러미에 대해 이야기할 때면 종종 포티지 트리에서 젠투 사용자들이 사용할 수 있는 프로그램의 제목을 의미합니다. 포티지 트리는 포티지가 프로그램을 관리(설치, 검색, 요청 등)하기 위해 필요로 하는 모든 정보가 들어간 ebuild 파일의 모음입니다.이 ebulid 파일들은 기본적으로 /usr/portage 안에 있습니다.
여러분이 관심있는 프로그램 제목에 대해 어떤 동작을 요청할 때마다 시스템의 기반 요소로서 ebuild를 사용할 것입니다. 그렇기 때문에 시스템의 ebuild를 주기적으로 갱신하여 포티지가 새 프로그램과 보안 갱신 등을 알리는 것은 매우 중요합니다.
포티지 트리 갱신
보통 포티지 트리는 빠른 증분 파일 전송 유틸리티 rsync로 갱신 합니다. emerge 명령을 rsync의 프론트엔드로 제공하는 만큼 포티지 트리 갱신은 상당히 간단합니다.
| 코드 예제 2.1: 포티지 트리 갱신하기 |
| # emerge --sync |
방화벽 제한때문에 rsync를 사용할 수 없다 하더라도 매일 생성하는 포티지 트리 스냅샷을 사용하여 포티지 트리를 갱신할 수도 있습니다. emerge-websync 도구는 여러분의 시스템에 최신 스냅샷을 가져오고 설치합니다.
| 코드 예제 2.2: emerge-websync 실행하기 |
| # emerge-websync |
emerge-websync를 사용하는 추가적인 장점은 관리자가 젠투 릴리즈 엔지니어링 GPG 키로 서명한 포티지 트리 스냅샷만 가져오도록 한다는 점입니다. 이에 대한 자세한 내용은 [포티지 기능]의 [검증된 포티지 트리 스냅샷 가져오기]에서 찾으실 수 있습니다.
프로그램 관리
프로그램 검색
프로그램의 제목으로 포티지 트리를 검색하려면 emerge의 내장 검색 기능을 사용할 수 있습니다. 기본적으로 emerge --search는 주어진 단어에 대해 (완전히 혹은 부분적으로) 일치하는 제목을 가진 꾸러미의 이름을 반환합니다.
예를 들어 pdf라는 이름을 포함한 모든 꾸러미를 검색하려면
| 코드 예제 3.1: pdf 이름을 가진 꾸러미 검색하기 |
| # emerge --search pdf |
이와 마찬가지로 설명에서 검색하려면 --searchdesc (또는 -S) 스위치를 사용할 수 있습니다.
| 코드 예제 3.2: pdf 관련 꾸러미 검색하기 |
| # emerge --searchdesc pdf |
출력 내용을 봤을 때 많은 정보가 주어진 알림을 보게 될 것입니다. 이 내용들은 확실히 이름표를 붙여놓았기 때문에 의미를 찾아보기 위해 그 이상 들어가지 않을 것입니다.
| 코드 예제 3.3: 'emerge --search' 출력 예제 |
* net-print/cups-pdf
Latest version available: 1.5.2
Latest version installed: [ Not Installed ]
Size of downloaded files: 15 kB
Homepage: http://cip.physik.uni-wuerzburg.de/~vrbehr/cups-pdf/
Description: Provides a virtual printer for CUPS to produce PDF files.
License: GPL-2
|
프로그램 설치하기
여러분이 원하는 프로그램 제목을 찾았다면 emerge로 프로그램을 쉽게 설치할 수 있습니다. 그냥 꾸러미 이름을 덧붙이시면 됩니다. 예를 들어 gnumetric을 설치한다고 할 때
| 코드 예제 3.4: gnumetric 설치하기 |
| # emerge gnumetric |
수많은 프로그램이 서로 의존관계가 있기 때문에 어떤 프로그램 꾸러미의 설치를 시도하면 이처럼 수많은 의존요소를 설치하게 됩니다. 포티지가 의존요소를 잘 관리하니 걱정하지 않으셔도 됩니다. 여러분이 어떤 꾸러며의 설치를 요청했을 경우 포티지가 설치할 꾸러미를 찾고 싶다면 --pretend 스위치를 덧붙이십시오. 예를 들자면
| 코드 예제 3.5: gnumetric 설치 가정하기 |
| #emerge --pretend gnumetric |
포티지에 꾸러미 설치를 요청하면 (필요하다면) 인터넷에서 필요한 소스코드를 내려받고 기본적으로 /usr/portage/distfiles에 저장할 것입니다. 그 다음에 압축을 풀고 컴파일한 다음 꾸러미를 설치할 것입니다. 포티지가 꾸러미를 설치하지 않고 소스코드를 다운로드하기만 원한다면 emerge명령에 --fetchonly를 덧붙이도록 합니다.
| 코드 예제 3.6: gnumetric 소스코드 내려받기 |
| # emerge --fetchonly gnumetric |
설치한 꾸러미 문서 찾기
대부분의 꾸러미는 문서가 딸려옵니다. 때때로 doc USE 플래그는 꾸러미의 문서를 설치할 것인지 말 것인지를 결정합니다. doc USE 플래그의 존재 유무는 emerge -vp <package name>명령으로 확인할 수 있습니다.
| 코드 예제 3.7: doc USE 플래그의 존재 유무 확인 |
| (물론, alsa-lib는 예시일 뿐입니다) # emerge -vp alsa-lib |
doc USE 플래그를 활성화 하는 가장 좋은 방법은 /etc/portage/package.use를 통해 꾸러미마다 활성화 하여 여러분이 보유하고 싶은 해당 꾸러미에 대한 문서를 획득하는 것입니다. 시스템 전체적으로 플래그를 활성화 하는 것은 순환 의존성 문제를 유발하는 것으로 알려져 잇습니다. 더 자세한 이야기에 대해서는 [USE 플래그]장을 읽어보시기 바랍니다.
꾸러미를 설치하고 나면 꾸러미에 대한 문서는 보통 /usr/share/doc 디렉터리 아래의 꾸러미 이름이 달린 하위디렉터리 밑에서 찾을 수 있습니다. app-portage/gentoolkit [꾸러미] (역자 주: gentoolkit 문서로의 연결 필요) 의 일부인 equery도구를 사용하면 설치한 모든 파일의 목록을 볼 수 있습니다.
| 코드 예제 3.8: 꾸러미 문서 불러오기 |
# ls -l /usr/share/doc/alsa-lib-1.0.14_rc1total 28 -rw-r--r-- 1 root root 669 May 17 21:54 ChangeLog.gz -rw-r--r-- 1 root root 9373 May 17 21:54 COPYING.gz drwxr-xr-x 2 root root 8560 May 17 21:54 html -rw-r--r-- 1 root root 196 May 17 21:54 TODO.gz (대신, 찾으려는 파일을 찾기 위해 equery를 사용합니다.)
/usr |
프로그램 제거하기
프로그램 꾸러미를 시스템에서 제거하려고 할 때 emerge --unmerge를 사용하십시오. 이 명령은 설치 이후 바뀐 프로그램의 설정 파일을 제외하고 여러분의 시스템에서 꾸러미로부터 설치한 모든 파일을 제거하도록 포티지에 알릴 것입니다. 설정 파일을 남겨줌으로서 꾸러미를 다시 설치하기로 했을때 꾸러미로 작업하는 것을 계속할 수 있게 해줍니다.
그러나 중요한 경고 를 해야겠습니다. 포티지는 제거하는 꾸러미가 다른 꾸러미에서 필요로 하는지에 대한 여부는 확인하지 않습니다. 여러분이 이 꾸러미를 제거할 때 여러분의 시스템을 깨는 중요한 꾸르미를 제거하려 할 때도 경고할 것입니다.
| 코드 예제 3.9: 시스템에서 gnumetric 제거하기 |
| emerge --unmerge gnumetric |
시스템에서 꾸러미를 제거할 때는, 프로그램을 설치했을 때 자동으로 설치한 꾸러미들의 의존요소는 그대로 남습니다. 제거할 수 있는 모든 의존요소를 포티지가 찾도록 하려면 emerge의 --depclean을 기능적으로 사용하도록 합니다. 이에 대해서는 다음에 이야기하도록 하겠습니다.
시스템 갱신하기
시스템의 완벽한 모양새를 유지하(고 최신 보안 갱신 요소를 설치하도록 알림을 받지 않으)려면 시스템을 주기적으로 갱신할 필요가 있습니다. 여러분이 처음 포티지 트리를 갱신할 때 포티지 트리에서 ebuild만 확인합니다. 포티지 트리를 갱신하면, emerge --update world로 시스템을 갱신할 수 있습니다. 다음 예제에서는 --ask 스위치를 사용하여 업그레이드할 꾸러미의 목록을 표시하고 계속 할 것인지에 대한 여부를 물을 것을 포티지에 요청하겠습니다.
| 코드 예제 3.10: 시스템 갱신하기 |
| # emerge --update --ask world |
포티지는 여러분이 설치한 프로그램의 최신 버전을 찾을 것입니다. 그러나 이는 여러분이 확실히 설치한 프로그램의 버전만을 확인할 것입니다 (프로그램의 목록은 /var/lib/portage/world에 있습니다). 이는 의존성까지 철저히 확인하진 않습니다. 이렇게 여러분이 의존 요소까지 갱신하고 싶으시다면 --deep 인자를 덧붙이도록 합니다.
| 코드 예제 3.11: 의존요소를 포함하여 시스템 갱신하기 |
| # emerge --update --deep world |
이는 여전히 모든 꾸러미를 의미하는 것은 아닙니다. 여러분의 시스템에 있는 일부 꾸러미는 컴파일 및 빌드과정에 필요하지만 꾸러미의 설치가 끝나면 이 의존성은 더이상 필요치 않습니다. 포티지는 이를 빌드 의존성이라고 부릅니다. 갱신 주기때마다 이들을 포함하려면 --with-bdeps=y를 덧붙이도록 합니다.
| 코드 예제 3.12: 전체 시스템 갱신하기 |
| # emerge --update --deep --with-bdeps=y world |
여러분은 시스템에 명시적으로 설치하지 않(지만 다른 프로그램의 의존요소로서 끌려옵니다)은 꾸러미에서 보안 갱신이 일어날 때,이 명령을 가끔씩은 실행해주는 것을 추천합니다.
어떤 [USE 플래그]를 최근 바꾸었다면, 그에 따라 --newuse를 추가하고 싶으실지도 모릅니다. 포티지는 플래그의 변경이 새 꾸러미의 설치 또는 존재하는 꾸러미의 재 컴파일을 요구하는 경우 이를 검증할 것입니다.
| 코드 예제 3.13: 완전한 갱신 수행 |
| # emerge --update --deep --with-bdeps=y --newuse world |
통함꾸러미(MetaPackages)
포티지 트리에서 어떤 꾸러미는 실제 내용을 포함하지는 않지만 꾸러미 모음을 설치하는데 사용합니다. 예를 들어 kde-meta 꾸러미는 의존요소로서의 다양한 KDE 관련 꾸러미를 시스템에 가져와서 완전한 KDE 환경으로 설치할 것입니다. 만약 이런 꾸러미를 시스템에서 오히려 제거하려 할 때, 이 꾸러미에 대해 emerge --unmerge를 실행하면, 이 꾸러미는 시스템에 남아있던 의존요소의 효과가 더 이상 없을 것입니다.
포티지는 또한 버려진 의존성을 잘 제거하는 기능을 갖추고 있지만, 프로그램의 사용가능성은 USE 플래그를 바꾸었을때 적용할 새로운 변경을 포함하여 전체 시스템을 완전히 먼저 업데이트 하도록 동적으로 의존합니다. 그 다음에는 버려진 의존성을 제거하기 위해 emerge --depclean을 실행할 수 있습니다. 이것이 끝나면 막 제거하였지만 더이상 필요하지 않은 프로그램의 이름에 동적으로 연결했던 프로그램들을 다시 빌드할 필요가 있습니다.
이 모든 과정을 다음 3개의 명령으로 처리합니다.
| 코드 예제 3.14: 버려진 의존성 제거하기 |
| # emerge --update --deep --newuse world # emerge --depclean |
revdep-rebuild는 gentoolkit 꾸러미에서 제거합니다. 이걸 먼저 이머지 하는것을 잊지 마십시오
| 코드 예제 3.15: gentoolkit 꾸러미 설치하기 |
| # emerge gentoolkit |
라이선스
포티지 버전 2.1.7부터 라이선스를 기반으로 하여 프로그램 설치를 수락 혹은 거절할 수 있습니다. 트리상의 모든 꾸러미는 ebuild에 LICENSE 엔트리를 가지고 있습니다. emerge --search packagename을 실행하면 꾸러미의 라이선스를 알려줄 것입니다.
기본적으로 포티지는 모든 라이선스를 허용하지만, 읽기를 요구하고 동의서에 동의여부를 확인해야 하는 최종 사용자 사용허가 동의서(EULA)는 제외됩니다.
허용할 라이선스를 제어하는 변수는 /etc/make.conf에 설정할 수 있는 ACCEPT_LICENSE 입니다.
| 코드 예제 4.1: /etc/make.conf의 기본 ACCEPT_LICENSE |
| ACCEPT_LICENSE="- @EULA" |
이 설정을 통해 설치 과정상 EULA의 내용을 승인하기 위해 상호작용이 필요한 프로그램은 설치되지 않을 것입니다. EULA가 없는 꾸러미가 설치될 것입니다.
/etc/make.conf에 전체적으로 ACCEPT_LICENSE를 설정하거나 각 페키지를 기반으로 /etc/package/package.license에 지정할 수 있습니다.
예를 들어 app-crypt/truecrypt의 truecrypt-2.7 라이선스를 허용하려 할 때, /etc/portage/package.license에 다음을 추가 합니다.
| 코드 예제 4.2:package.license에 truecrypt 라이선스 지정하기 |
| app-crypt/truecrypt truecrypt-2.7 |
이를 통해 truecrypt-2.7 라이선스를 가진 truecrypt 버전을 설치하지만, truecrypt-2.8 라이선스를 가진 프로그램은 설치하지 않습니다.
중요: 라이선스는 /usr/portage/license에 저장하며 라이선스 그룹은 /usr/portage/profiles/license_groups에 유지합니다. 대문자로 이루어진 요소들 중 첫번째 항목은 라이선스 그룹의 이름이며, 모든 항목의 다음에는 각각의 라이선스를 의미합니다
ACCEPT_LICENSE에 정의한 라이선스 그룹은 @ 기호가 붙습니다. 여기 전체적으로 적용할 시스템에 있는 예제는 일부 다른 그룹과 제각각의 라이선스와 마찬가지로 GPL 호환 라이선스 그룹을 처리합니다.
| 코드 예제 4.3: /etc/make.conf의 ACCEPT_LICENSE |
| ACCEPT_LICENSE="@GPL-COMPATIBLE @OSI-APPROVED @EULA atheros-hal BitstreamVera" |
자유 소프트웨어 자유 문서 만 사용한다면 다음 설정을 사용하도록 합니다.
| 코드 예제 4.4: free 라이선스만 사용하기 |
| ACCEPT_LICENSE="-* @FREE" |
이 경우 "free"는 대부분 보통 FSF나 OSI에 설명 되어 있습니다. 이 요구사항을 만나지 않는 라이선스를 가진 꾸러미는 시스템에 설치되지 않을 것입니다.
포티지가 징징거릴 때...
슬롯, 가상 카테고리, 브랜치, 아키텍처, 프로파일
우리가 이전에 이해하던 바로는, 포티지는 굉장히 강력하고 다른 프로그램 관리도구에서 빠진 수많은 기능을 지원한다고 했습니다. 이러한 점을 이해하려면 더 자세히는 말고 적당한 선에서 포티지의 일부 모양새를 설명하도록 하겠습니다.
포티지에서 단일 꾸러미의 각기 다른버전이 시스템에 공존할 수 있습니다. 다른 배포판에서는 버전에 이름을 같이 붙이려 (예를 들자면 freetype과 freetype2와 같이) 하지만,포티지는 슬롯이라는 기술을 사용합니다. ebuild는 이 버전에 대해 각각의 SLOT을 선언합니다. 제각각의 슬롯이 부여된 ebuild는 시스템에 공존할 수 있습니다. 예를 들어 freetype 꾸러미는 ebuild에 SLOT="1"과 SLOT="2"가 있습니다.
차단한 꾸러미
가려놓은 꾸러미
USE 플래그 바꾸기 필요
| 코드 예제 5.5: USE 플래그 변경 요구사항에 대한 포티지 경고 |
The following USE changes are necessary to proceed:
>=app-text/feelings-1.0.0 test |
--autounmask를 설정하지 않았을 떄 다음과 같은 오류메시지가 뜰 때도 있습니다.
| 코드 예제 5.6: 필요한 USE 플래그 변경에 대한 포티지 오류 |
| emerge: there are no ebuilds built with USE flags to satisfy "app-text/feelings[test]". !!! One of the following packages is required to complete your request: |
다른 꾸러미에만 의존하지 않는 꾸러미를 설치하려 할 때 발생하는 어떤 경고나 오류가 발생하지만 어떤 USE 플래그 (또는 USE 플래그 모음) 와 함께 꾸러미를 반드시 빌드해야 할 필요가 있을때에도 그렇습니다. 주어진 예제에서는 app-text/feelings 꾸러미가 USE="test" 로 빌드하는 것을 필요로 하지만 시스템에 이 플래그를 설정하지 않은 상황입니다.
이 문제를 해결하려면 /etc/portage/make.conf의 전역 USE 플래그에 요구하는 USE 플래그를 추가하거나 /etc/portage/package.use에 지정 꾸러미에 대한 플래그를 설정합니다.
빠진 의존성
| 코드 예제 5.7: 빠진 의존성에 대한 포티지 경고 |
| emerge: there are no ebuilds to satisfy ">=sys-devel/gcc-3.4.2-r4".
|
시스템에 존재하지 않는 다른 꾸러미에 의존하여 프로그램을 설치하려고 했습니다. 이미 알려진 문제라면 버그질라를 확인해주시고, 없다면 보고해 주시기 바랍니다. 브랜치를 뒤섞어 엎어놓지 않는한 이 일은 발생하지 않겠지만, 그렇기 때문에 이런 현상은 버그입니다.
애매한 ebuild 이름
| 코드 예제 5.9: 애매한 ebuild 이름에 대한 포티지 경고 |
| [ Results for search key : listen ] [ Applications found : 2 ] |
설치하려는 프로그램이 하나 이상의 꾸러미와 관련된 이름을 지니고 있습니다. 이럴 경우 카테고리 이름을 같이 넣어줘야 합니다. 포티지는 선택할 가능한 일치요소를 알려줄 것입니다.
순환 의존성
| 코드 예제 5.9: 순환 의존성에 대한 포티지 경고 |
| !!! Error: circular dependencies:
|
여러분이 설치하려는 둘 (이상) 의 꾸러미가 서로 의존성을 가져 설치할 수 없습니다. 이는 거의 포티지 트리의 버그 같습니다. 좀 지난 후 다시 트리를 동기화 한 다음 재시도 해주시기 바랍니다. 또한 이미 알려진 문제라면 버그질라를 확인할 수 있는데, 없다면 보고하십시오.
가져오기 실패
| 코드 예제 5.10: 가져오기 실패에 대한 포티지 경고 |
| !!! Fetch failed for sys-libs/ncurses-5.4-r5, continuing...
(...) |
포티지가 다른 프로그램의 (쓸 수 있는 경우) 설치를 계속하려고 할 때 주어진 프로그램에 대한 소스코드를 내려받을 수 없습니다. 이 문제는 올바르게 동기화 하던 미러가 어긋났다거나 ebuild가 잘못된 위치를 가리켰기 때문에 발생할 수 있습니다. 어떤 이유 때문에 소스 코드가 있는 서버가 먹통이 되었을 수도 있었습니다.
시스템 프로파일 보호
| 코드 예제 5.11: 프로파일로 보호하는 꾸러미에 대한 포티지 경고 |
| !!! Trying to unmerge package(s) in system profile. 'sys-apps/portage' !!! This could be damaging to your system. |
시스템의 핵심 꾸러미를 제거하려 요청했습니다. 이런 메시지가 뜨면 여러분의 프로파일에 필요하다고 나열된 꾸러미이기 때문에 시스템에서 제거해서는 안되겠습니다.
다이제스트 검증 실패
가끔 꾸러미를 이머지 하려다 보면 다음 메시지가 떠서 실패하기도 합니다.
| 코드 예제 5.12: 다이제스트 검증 실패 |
| >>> checking ebuild checksums !!! Digest verification failed: |
이는 포티지 트리에 뭔가 문제가 있다는 이야기입니다. 종종 개발자들이 꾸러미를 트리로 커밋할때 실수를 만들 때도 있기 때문입니다.
다이제스트 검증이 실패하면 꾸러미의 다이제스트를 다시 만들려고 하지 마십시오.ebuild foo manifest를 실행해도 문제는 고쳐지지 않을 것입니다. 사실 이렇게 하면 대부분 일을 더 꼬이게 할 것입니다!
대신 트리가 올바르게 잡힐 때까지 한두시간 정도 기다려보시기 바랍니다. 올바르지 않은 방법으로 오류가 나타났을 수도 있는 것이지만, 포티지 트리가 서서히 자리를 잡는데 시간이 좀 걸릴 수가 있습니다. 기다리는 동안에 버그질라를 확인해보시고 누군가가 이 문제를 보고했는지 찾아보시기 바랍니다. 만약 내용이 없다면 가서 깨진 꾸러미의 문제를 알려주시기 바랍니다. :)
중요: 이는 여러번 동기화 할 수 있다는걸 의미하는 것이 아닙니다! rsync 정책에 언급(emerge --sync를 실행할 때) 한 대로 자주 동기화를 수행하는 사용자는 추방됩니다! 사실 다음에 동기화 할 때까지 기다려서 rsync서버에 부하를 주지 않는게 가장 좋습니다.
