포티지는 아마도 소프트웨어 유지관리에 있어 젠투의 가장 주목할만한 혁신 기술이 아닌가 싶습니다. 특징에 있어 이것의 높은 유연성과 방대한 양은 리눅스를 위해 존재하는 최상의 소프트웨어 유지관리 도구로서 종종 눈에 보일 것입니다.

포티지는 Python과 Bash로 완벽하게 작성되었으며, 이로하여금 사용자에게 두 언어가 스크립트 언어로 완전히 보일 수 있습니다.

대부분 많은 사용자 분들은 emerge 도구를 이용하여 Portage와 작업을 하게 될 것입니다. 이 챕터는 emerge 맨 페이지로부터 가능한 정보들을 복사하였다는 그런의미가 아닙니다. emerge의 선택사항요소에 대한 항목별 완전한 요소를 참조하기 위해서는, 맨 페이지를 참조하시기 바립니다.:

예제 1-1 : emerge 맨 페이지 보기

$ man emerge

우리가 패키지에 대해 이야기할때는, 젠투 사용자가 포티지 트리를 통해 종종 사용 가능한 소프트웨어 타이틀을 의미합니다. 포티지 트리는 ebuild의 모임이며, 이 파일들은 포티지가 프로그램을 유지관리하는데 필요한 모든 정보를 포함하고 있습니다(설치, 검색, 요청 등등). 이들 ebuild는 /usr/portage 안에 기본으로 존재합니다.

소프트웨어 제목에 관계된 어떤 동작을 수행하기 위해서 Portage에게 언제 요청하든지간에 Portage는 시스템의 기반으로서 ebuild를 사용할 것입니다. 그래서 정기적으로 시스템의 ebuild를 갱신하고 Portage가 새로운 소프트웨어나 보안 업데이트 등에 대해 알게 하는 것이 중요합니다.

포티지 트리는 종종 속도가 점진적으로 붙는 파일 전송 유틸리티인 rsync를 통해 갱신됩니다. 갱신은 rsync를 사용하기 위한 프론트엔드인 emerge 명령으로 제공되어 적절히 간단합니다.

예제 2-1 : 포티지 트리 갱신

# emerge --sync

만약 방화벽 제한으로 인해 rsync를 사용할 수 없다면, 매일 생성된 포티지 트리 스냅샷을 이용하여 포티지트리를 업데이트 할 수 있습니다. emerge-websync 도구는 자동적으로 시스템으로 최근 스냅샷을 들여오고 설치합니다.

예제 2-2 : emerge-websync 실행

# emerge-webrsync

포티지 트리를 통해 다음 소프트웨어 제목을 검색학때 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로 쉽게 설치할 수 있습니다. 단지 패키지 이름을 덧붙이기만 하면 됩니다. 예를 들어 gnumeric을 설치한다면...

예제 3-4 : gnumeric 설치

# emerge gnumeric

수많은 어플리케이션이 서로 의존하는 까닭에, 많은 소프트웨어 설치 시도는 의존관계가 있는 더 많은 것들의 설치 결과를 가져올 것입니다. 독자 여러분이 많은 패키지를 설치할때 포티지가 설치할 것들을 찾아보려면 --pretend 스위치를 다음 예와 같이 추가합니다.

예제 3-5 : gnumetic을 설치하기 위한 것들을 나타내기

# emerge --pretend gnumeric

포티지로 하여금 패키지를 설치할 것을 요청할때, 포티지는 필요한 소스코드를 인터넷으로부터 (필요하다면) 내려받고, 기본적으로 /usr/portage/distfiles에 저장합니다. 다음에는 이것이 패키지를 언팩할 것이며 컴파일하고 설치할 것입니다. 만약 포티지가 소스코드를 설치하지 않고 그냥 내려받기만을 원한다면 emerge 명령에 --fetchonly 선택사항요소를 추가하도록 합니다.

예제 3-6 : gnumeric을 위한 소스 내려받기

# emerge --fetchonly gnumeric

수많은 패키지는 그들 자신의 문서와 같이 딸려옵니다. 때로는 doc USE 플래그가 문서를 설치할 것이냐 말 것이냐의 여부를 결정합니다. doc USE 플래그의 존재를 확인하려면 emerge -vp <package name> 명령을 사용합니다.

예제 3-7 : doc USE 플래그의 존재여부를 확인하기

(alsa-lib is just an example, of course.)
# emerge -vp alsa-lib
[ebuild  N    ] media-libs/alsa-lib-1.0.14_rc1  -debug +doc 698 kB

doc USE 플래그를 사용가능하게 하는 제일 좋은 방법은 /etc/portage/package.use를 통해 패키지별로 사용하게끔하는 것인데, 이렇게 해서 해당 패키지만을 위한 필요로하는 문서를 얻어낼 수 있습니다. 이 플래그를 전체적으로 사용하게 하는 방법은 순환 의존 문제를 야기하는 것으로 알려져 있습니다. 더 많은 정보를 얻으려면 USE 플래그 챕터를 보시기 바랍니다.

패키지 하나가 설치되었으면 이의 문서는 일반적으로 /usr/share/doc 디렉토리 아래서 패키지 이름으로 된 하위디렉토리로서 찾을 수 있습니다. 또한 app-portage/gentoolkit 패키지의 일부로서 존재하는 equery툴로 하여금 설치된 모든파일들을 나열해볼 수 있습니다.

예제 3-8 : 패키지 문서 위치 지적

# ls -l /usr/share/doc/alsa-lib-1.0.14_rc1
total 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

(Alternatively, use equery to locate interesting files:)
# equery files alsa-lib | less
media-libs/alsa-lib-1.0.14_rc1
* Contents of media-libs/alsa-lib-1.0.14_rc1:
/usr
/usr/bin
/usr/bin/alsalisp
(Output truncated)

소프트웨어 패키지를 제거하려 할때 emerge --unmerge 를 사용합니다. 이는 포티지로 하여금 설치 이후에 변경된 프로그램에 대한 환경설정파일들을 제외하고 시스템으로부터 패키지에 딸려 설치된 모든 파일들을 제거할 것을 emerge 에 요청할 것입니다. 환경설정 파일을 남겨두는 것은 이 소프트웨어를 다시 설치하기로 결정했을 경우 패키지 설치와 동시에 이전에 설정했던 사항을 따라 실행하는 것을 계속할 수 있도록합니다.

그러나 대단이 위험한 것이 적용됩니다. 포티지는 제거 대상이 다른 패키지에 의해 필요한 것인지 체크하지는 않을 것입니다. 이는 그러나 시스템을 깨뜨릴만한 중요한 패키지를 unmerge하기 원할때 경고할 것입니다.

예제 3-9 : 시스템으로부터 gnumeric 제거

# emerge --unmerge gnumeric

시스템으로부터 패키지를 제거할때, 덩달아 설치된 소프트웨어가 남아있을 경우 해당 패키지의 의존성은 이미 자동으로 설치된 것입니다. 포티지가 제거가능한 의존성을 가리키도록 하려면 emerge의 --depclean 선택사항요소를 기능적으로 사용합니다. 이에 대해서는 나중에 설명할 것입니다.

시스템의 완벽한 모양새를 유지하려면(그리고 최신 보안 업데이트 설치에 대해 언급하지 않으려면 주기적으로 시스템을 갱신할 필요가 있습니다. Portage가 단지 포티지 트리의 ebuild를 검사하기 때문에 우선 포티지 트리를 먼저 갱신해야만 합니다. 포티지 트리가 갱신되었을때, emerge --update world명령으로 시스템을 갱신할 수 있습니다. 다음 예제에서, 우리는 또한 --ask 스위치를 사용하여 포티지가 패키지 리스트를 보여주어 업그레이드를 "계속" 할 것인지에 대한 물음을 하도록 할 것입니다.

예제 3-10 : 시스템 갱신

# emerge --update --ask world

그렇게 하면 포티지는 설치된 어플리케이션의 새로운 버전을 검색할 것입니다. 그러나 명시적으로 설치한 어플리케이션을 위한 버전에 대해서만 검증할 것입니다 (어플리케이션은 /var/lig/portage/world 에 나열되어 있습니다) - 이는 그들 사이의 의존성을 철저히 점검하지는 않습니다. 시스템의 모든 단일 패키지를 업데이트 하기 원할때 --deep 인수를 추가하십시오.

예제 3-11 : 시스템 전체 갱신

# emerge --update --deep world

보안 업데이트 또한 시스템에 명시적으로 설치하지 않은 패키지들에 포함되는데( 그러나 다른 프로그램들로부터의 의존성과 같은 이유로 인해 끌려왔습니다), 이 명령을 곧바로 한번 실행하는 것을 추천합니다.

어떤 USE 플래그를 최근 변경했다면 --newuse또한 추가하기를 원할지도 모릅니다. 그러면 포티지는 변경사항으로 하여금 새로운 패키지의 설치를 요구한다거나 존재하는것에 대한 재컴파일을 요구할 경우 이를 검증할 것입니다.

예제 3-12 : 전체 업그레이드 수행

# emerge --update --deep --newuse world

포티지 트리에서 어떤 패키지는 실제적인 내용물을 포함하고 있지는 않지만 패키지 모음을 설치하는데 사용됩니다. 예를 들어서 kde 패키지는 KDE와 관련된 패키지를 서로 의존적인것처럼 끌어와서 시스템에 완벽한 KDE 환경을 설치할 것입니다.

만약 이런 패키지를 언젠가 시스템에서 제거하려 한다면, 패키지에 대해 emerge --unmerge를 수행하는 것은 시스템에 남아있는 많은 의존성을 갖지 않을 것입니다.

포티지는 기능적으로 상위종속성을 잘 제거하지만, 소프트웨어의 사용가능성은 시스템 전체를 완벽하게 먼저 업데이트 할 필요가 있게 동적으로 의존하기 때문에, USE플래그를 변경하였을때 독자여러분이 적용한 새로운 변경사항을 포함하게 됩니다. 이 다음에는 emerge --depclean을 실행하여 상위종속성이 제거된 의존성을 없앨 수 있습니다. 이것이 왼료되면 방금 제거된 소프트웨어 타이틀로 동적으로 연결된 어플리케이션을 다시 빌드할 필요가 있지만 그것들이 더이상 필요한 것은 아닙니다.

이 모든 것이 다음 세가지 명령으로 다루어집니다. 예제 3-13 : 상위종속성이 제거된 의존성 제거

# emerge --update --deep --newuse world
# emerge --depclean
# revdep-rebuild

revdep-rebuild은 gentoolkit패키지에서 제공됩니다. 이것을 먼저 emerge 하는 것을 잊지 마십시오.

예제 3-14 : gentoolkit 패키지 설치

# emerge gentoolkit

우리가 일전에 말한바와 같이, 포티지는 엄청나게 강력하고 다른 소프트웨어 관리 도구에서는 부족한 많은 특징들을 지원합니다. 이를 이해하기 위해서 우리는 더더욱 자세하게 들어가지 않는 포티지의 일부 면에 대해 설명하겠습니다.

포티지에서는 단일 패키지의 각기 다른 버전들이 시스템에 공존할 수 있습니다. 한편 다른 배포판들이 그들 패키지의 버전으로 이름을 따르지만(freetype과 freetype2와 같이...) 포티지는 SLOT이라고 부르는 기술을 사용합니다. ebuild는 이런 버전을 위해 각각의 SLOT을 선언합니다. 각기 다른 SLOT과 함께 존재하는 ebuild들은 시스템에 공존할 수 잇습니다. 예를 들어 freetype 패키지는 SLOT="1"과 SLOT="2"와 함께 ebuilds를 지니고 있습니다.

또판 같은 기능성을 제공하는 패키지라 하지만 다르게 표현될 수도 있습니다. 예를 들어 metalogd, sysklogd,그리고 syslog-ng들은 모두 시스템 로거들입니다. 어플리케이션들은 "시스템 로거"로서의 사용가능성에 의지하는데 이들은, metalogd를 예로 들어 다른 어떤 시스템 로거만큼 좋은 선택인 것처럼 서로에게 의존적이지 않습니다. 포티지는 virtual을 통해 각각의시스템 로거에 대하여 virtual/syslog를 제공하여 어떤 어플리케이션이든지 virtual/syslog에 의존될 수 있는 것을 허용합니다.

포티지 트리 내의 소프트웨어는 다른 브랜치에 귀속될 수 있습니다. 기본적으로 독자여러분의 시스템은 단지 젠투가 안정적이다 라고 간주하는 패키지에 대해서만 수용할 뿐입니다. 대부분의 새로운 소프트웨어 타이틀들에 대해 커밋했을때 테스팅 브랜치에 추가되고 이는 안정화되기 위해 좀더 많은 테스트가 완료되는 것이 필요함을 의미합니다. 비록 포티지 트리에서 그런 소프트웨어를 위한 ebuilds를 볼 수 있겠지만 포티지는 안정화 브랜치에 위치되기 전에는 업데이트 되지 않을 것입니다.

어떤 소프트웨어의 경우에는 일부 아키텍처에 대해서만 사용가능거나 더 많은 테스트가 필요하거나, 다른 아키텍처에서 패키지가 동작하는지에 대한 검증을 하기위해 개발자가 포티지 트리에 커밋한 소프트웨어가 사용 불가능할때도 있습니다.

각각의 젠투 설치관리자는 일반적으로 시스템이 기능을 수행하기 위해 필요한 패키지 목록에 대한 다른 정보들간의 사이에서 일정한 프로파일이 붙습니다.

예제 4-1 : 차단된 패키지에 대한 포티지의 경고 (--pretend 사용)

[blocks B     ] mail-mta/ssmtp (is blocking mail-mta/postfix-2.2.2-r1)

예제 4-2 : 차단된 패키지에 대한 포티지의 경고 (--pretend 사용 안함)

!!! Error: the mail-mta/postfix package conflicts with another package.
!!!        both can't be installed on the same system together.
!!!        Please use 'emerge --pretend' to determine blockers. 

Ebuild는 의존성에 대해 포티지에게 알려주는 특정한 필드들이 있습니다. 여기에는 두가지 가능한 의존성이 있는데 하나는 DEPEND에 명시된 빌드 의존성, 그리고 다른 하나는 RDEPEND에 명시된 실행시간 의존성입니다. 이들 의존성 중 하나가 명시적으로 패키지로서 표시가 되었거나 호환되지 않는 가상 패키지로 표시가 되었다면, 이는 차단을 유발하게 됩니다.

이런 차단현상을 수정하기 위해서는 설치하지 않은 패키지를 선택하거나 충돌하는 하는 패키지를 먼저 언머지하는 방법을 선택할 수 있습니다. 주어진 예제에서, 독자여러분은 postfix 를 설치하지 않거나 ssmtp를 먼저 제거하거나 둘중 하나를 선택할 수 있습니다.

또한

또 다른 가능성을 들자면 아직 설치되지도 않은 두 패키지가 서로를 차단하는 경우도 있습니다. 이런 드문 경우에는 왜 두 패키지를 다 설치할 필요가 있는지를 찾아야 합니다. 대부분의 경우에는 그들 패키지둥 하나만 으로도 가능합니다. 만약 그렇지 않다면, 젠투 버그추적 시스템에 버그를 등록해주세요!

예제 4-3 : 가려진 패키지에 대한 경고

!!! all ebuilds that could satisfy "bootsplash" have been masked. 

예제 4-4 : 가려진 패키지에 대한 경고 - 이유

!!! possible candidates are:

- gnome-base/gnome-2.8.0_pre1 (masked by: ~x86 keyword)
- lm-sensors/lm-sensors-2.8.7 (masked by: -sparc keyword)
- sys-libs/glibc-2.3.4.20040808 (masked by: -* keyword)
- dev-util/cvsd-1.0.2 (masked by: missing keyword)
- games-fps/unreal-tournament-451 (masked by: package.mask)
- sys-libs/glibc-2.3.2-r11 (masked by: profile)

시스템에서 사용가능하지 않은 패키지를 설치하기 원할때 이런 가림 에러 메세지를 받을 것입니다. 시스템에서 사용가능한 다른 어플리케이션을 설치해보려 하거나 패키지가 사용가능해질 때까지 기다려보아야 합니다. 왜 패키지가 가려졌는지는 항상 이유가 있습니다.

• ~arch 키워드는 어플리케이션이 안정화되기까지 충분히 테스트 되지 않음을 의미합니다. 며칠 혹은 몇주 정도 기다렸다 다시 해봅니다.
• -arch 키워드나 -*키워드는 어플리케이션이 독자여러분이 보유한 시스템의 아키텍처에서 동작하지 않음을 의미합니다. 만약 패키지가 동작한다고 믿는다면 버그질라 웹사이트에 버그를 알려주세요.
• missing keyword 는 독자여러분이 보유한 시스템의 아키텍처에서 아직 테스트되지 않았음을 의미합니다. 아키텍처 포팅팀에 패키지를 테스트해달라고 요청하거나 그것들에 대해 직접 테스트하여 버그질라 웹사이트에 발견사항을 알려주시기 바랍니다.
• package.mask 는 패키지가 깨진걸 발견했거나, 불안정하거나, 무엇인가 잘못되어 "사용금지"와 같이 신중하게 표기된 것을 의미합니다.
• profile 은 프로파일에 적합하지 않은 패키지임이 발견됨을 의미합니다. 이것을 설치하거나 독자여러분이 사용하는 프로파일과 호환되지 않거나 하면 이 어플리케이션은 독자여러분의 시스템을 망칠 것입니다.

예제 4-5 : 누락된 의존성에 대한 포티지 경고

emerge: there are no ebuilds to satisfy ">=sys-devel/gcc-3.4.2-r4".

!!! Problem with ebuild sys-devel/gcc-3.4.2-r2
!!! Possibly a DEPEND/*DEPEND problem. 

독자여러분이 설치하려는 어플리케이션은 시스템에서 사용가능하지 않은 다른 패키지에 의존성이 걸려있습니다. 알려진 문제라면 버그질라를 확인해보시고 그렇지 않다면 알려주시기 바랍니다. 브랜치를 뒤섞지 않았다면 이런 일이 일어나지 않을 뿐더러 버그일 것입니다.

예제 4-6 : 혼동되는 ebuild 이름에 대한 포티지 경고

!!! The short ebuild name "aterm" is ambiguous.  Please specify
!!! one of the following fully-qualified ebuild names instead:

    dev-libs/aterm
    x11-terms/aterm

설치하고자 하는 어플리케이션은 하나 이상의 패키지에 대응하는 이름을 가지고 있습니다. 분류 이름을 같이 잘 포함시킬 필요가 있습니다. 포티지는 어디서부터 선택할지 가능한 일치사항을 알려줄 것입니다.

예제 4-7 : 순환 의존성에 대한 포티지 경고

!!! Error: circular dependencies: 

ebuild / net-print/cups-1.1.15-r2 depends on ebuild / app-text/ghostscript-7.05.3-r1
ebuild / app-text/ghostscript-7.05.3-r1 depends on ebuild / net-print/cups-1.1.15-r2 

독자 여러분이 설치하기 원하는 둘(혹은 그 이상)의 패키지에 대해 서로 의존성이 걸려있거나 하여 설치되지 않을 수 있습니다. 이는 대부분 포티지 트리의 버그와 비슷합니다. 오랜 시간 후에 다시 동기화 하고 시도해보기 바랍니다. 독자 여러분 또한 이런 문제가 알려졌다면 버그질라를 확인해볼 수도 있습니다. 만약 그렇지 않다면 이를 알려주세요.

• 크리티컬한 패키지가 아니라면 둘 중 하나, 혹은 둘 다 지워버리고 설치하는것도 방법이 됩니다. - 송효진

예제 4-8 : 불러오기 실패에 대한 포티지 경고

!!! Fetch failed for sys-libs/ncurses-5.4-r5, continuing...
(...)
!!! Some fetch errors were encountered.  Please see above for details.

포티지는 주어진 어플리케이션의 소스를 다운로드 할 수 없었고, (만약 적절하다면)다른 어플리케이션의 설치로 계속할 수 없을 것입니다. 이러한 실채는 미러가 올바르게 동기화 되지 않았거나 ebuild가 잘못된 위치를 가리켰기 때문입니다. 소스가 존재하는 서버가 어떤 이유로 인해 다운될 수도 있습니다.

해당증상이 여전히 일어난다면 한시간쯤 후에 다시 시도해보세요.

예제 4-9 : 프로파일 보호된 패키지에 대한 포티지 경고

!!! Trying to unmerge package(s) in system profile. 'sys-apps/portage'
!!! This could be damaging to your system.

시스템의 주요 패키지의 일부인 패키지를 지우려 요청하였습니다. 이 패키지는 필수적인 프로파일에 나열되었으며, 따라서 시스템에서 제거되면 안 될 것입니다.

때론 패키지를 emerge 할때, 다음 메세지를 볼 수 있습니다.

예제 4-10 : 개요 검증 실패

>>> checking ebuild checksums
!!! Digest verification failed:

이는 포티지 트리에 있어 뭔가가 잘못되었다는 표시입니다. 이런 이유는 종종 개발자가 포티지 트리에 패키지를 커밋할때 실수를 저지르는 이유 때문인지도 모르겠습니다.

개요 검증 실패가 발생했을때 독자여러분 스스로가 re-digest(번역불능...)하려 하지 마십시오. ebuild foo manifest 를 실행한다고 해서 이 문제가 수정되는것이 아닙니다. 이렇게 해서는 거의 틀림없이 잘못된 결과를 가져올 것입니다.

하지만 한두시간 정도 포티지 트리가 안정되기 위해 기다리십시오. 이는 문제가 바로 표시가 되었지만, 포티지 트리가 조금씩 고쳐지는데 약간의 시간이 걸릴수도 있습니다. 그걸 기다리는 동안 버그질라를 확인해보시고 어떤 누군가가 해당 문제를 아직 안올렸는지 보십시와. 그렇지 않다면 그곳에 가서 깨진 패키지에 대한 버그를 알려주시기 바랍니다.

버그가 수정되었다는 것을 봤다면, 수정된 개요를 가져오기 위해 재동기화 하길 원할 것입니다.

중요 : 이것은 포티지 트리를 다중시간대에 재동기화 할 수 있다는 의미가 아닙니다! rsync정책에 대해 언급했듯이 (emerge --sync 실행시), 동기화를 너무 자주하는 사용자들은 추방될 것입니다. 사실, 다음 동기화 계획이 있기 전까진 그냥 기다리는 것이 좋기 때문에 rsync 서버에 과부하를 주어서는 안됩니다.

이전으로 가기