Gentoo Logo

[ << ] [ < ] [ ホーム ] [ > ] [ >> ]


1. Portageについて

目次:

1.a. Portageへようこそ

PortageはGentooのソフトウェア管理における最も注目すべき革新と言えるでしょう。 その高い柔軟性と非常に多くの機能により、Linuxで利用できる最高のソフトウェア管理ツールとされることがよくあります。

Portageは全てPythonBashによって書かれており、 両方ともスクリプト言語であるため、ユーザーにとって全体的に見通しのよいものになっています。

ほとんどのユーザーがemergeツールを通してPortageを利用しています。 この章はemergeのmanページで得られる情報の複製を意図したものではありません。 emergeのオプションについての完全な概要を得るためには、manページを調べてください。

コード表示 1.1: emergeのmanページを読む

$ man emerge

1.b. Portageツリー

ebuild

パッケージについて話す場合、たいていは、GentooユーザーがPortageツリーを通して利用可能なソフトウェア名を意味しています。 Portageツリーはebuildという、Portageがソフトウェアを維持管理する(インストール、検索など)ために必要な全ての情報を含んだファイルのコレクションです。 デフォルトでは、これらebuildは/usr/portageに置かれています。

Portageにソフトウェア名に関して、何か実行するよう指示するときはいつでも、システムにあるebuildがベースに使われます。 そのため、システムのebuildを定期的に更新することが重要です。 そうすれば、新しいソフトウェアやセキュリティアップデートなどを利用することができます。

Portageツリーの更新

Portageツリーは通常rsyncという高速差分ファイル転送ユーティリティで更新されます。 更新はrsyncのフロントエンドを提供するemergeコマンドを使うという、とても簡単なものです。

コード表示 2.1: Portageツリーを更新する

# emerge --sync

もしファイアーウォールの制限によりrsyncが実行できないときには、毎日作成されるPortageツリーのスナップショットを利用することによってPortageを更新することができます。 emerge-webrsyncツールは自動的に最新のスナップショットを取得し、システムにインストールしてくれます。

コード表示 2.2: emerge-webrsyncを実行

# emerge-webrsync

emerge-webrsyncを使うとGentooリリースエンジニアリングチームのGPG鍵でサインされているPortageツリーのスナップショットでツリーを更新できるという利点もあります。 詳しくはPortageの機能のセクションの検証済みのPortageツリースナップショットを取得するを参照してください。

1.c. ソフトウェアのメンテナンス

ソフトウェアの検索

Portageツリーからソフトウェア名を検索するには、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

たくさんのアプリケーションがお互いに依存し合っているため、あるソフトウェアをインストールしようとすると、 結果的にいくつかの依存関係もインストールすることになるでしょう。 ご心配なく、Portageは依存関係をうまく扱ってくれます。 もしパッケージをインストールするときにPortageが何をインストールしようとしているか確かめたい場合には、 --pretend引数を追加します。例えばこのようにします。

コード表示 3.5: gnumericをインストールするふりをする

# emerge --pretend gnumeric

Portageにパッケージをインストールするよう要求したときは、 必要なソースコードをインターネットからダウンロードし、 デフォルトでは/usr/portage/distfilesに保存します。 この後、ソースコードが展開され、コンパイルが実行されて、パッケージがインストールされます。 Portageにソースをダウンロードするだけでインストールを行って欲しくないときには、 emergeコマンドに--fetchonlyコマンドを追加します。

コード表示 3.6: gnumericのソースコードをダウンロード

# emerge --fetchonly gnumeric

インストール済みパッケージのドキュメントを検索

多くのパッケージはドキュメントと共にインストールされます。 docUSEフラグでパッケージのドキュメントをインストールするかしないかが決まる場合もあります。 現在のdocUSEフラグを確認するにはemerge -vp <package name>コマンドを使用します。

コード表示 3.7: 現在のdoc USEフラグを確認

(もちろんalsa-libはただの例です)
# emerge -vp alsa-lib
[ebuild  N    ] media-libs/alsa-lib-1.0.14_rc1  -debug +doc 698 kB

/etc/portage/package.useによってパッケージごとにdocUSEフラグを有効にする事をおすすめします。 そうすれば、興味のあるパッケージの分だけドキュメントを取得できるようになります。 このフラグをシステム全体で有効にしてしまうと、循環依存の問題を起こす原因となることが知られています。 詳しくは、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

(このほかにも、equeryを使用してファイルの位置を表示する方法もあります)
# 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
(省略)

ソフトウェアの削除

システムからパッケージを削除したいときは、emerge --unmergeを利用します。 これはPortageにパッケージによってインストールされた全てのファイルを削除するよう命令します。 ただし、インストール後に変更されたアプリケーションの設定ファイルは削除されません。 設定ファイルを残しておくことで、再びインストールすれば、パッケージは適切に動作します。

しかし、大きな警告があります:Portageは削除したいパッケージが他のパッケージから必要とされているかを確認しません。 しかし、少なくともunmergeするとシステムを破壊する様な重要なパッケージを削除するときにはPortageに警告されます。

コード表示 3.9: gnumericをシステムから削除

# emerge --unmerge gnumeric

システムからパッケージを削除するときには、インストール時に依存関係により自動的にインストールされたソフトウェアは残されます。 依存関係でインストールされたソフトウェアから削除可能なものを全て検索するには、emerge--depclean引数を利用します。 これについては後で話します。

システムの更新

システムを完全な形に保つ(最新のセキュリティアップデートをインストールする様に言われない為にも)には、システムを定期的に更新する必要があります。 Portageはツリーの中のebuildsのみ確認するので、最初にPortageツリーを更新しなければなりません。 Portageツリーが更新されたら、emerge --update @worldでシステムを更新できます。 次の例では--ask引数を使用しています。 これは、更新するパッケージの一覧をPortageに表示させ、続行するかを尋ねます。

コード表示 3.10: システムを更新する

# emerge --update --ask @world

Portageはインストールされているアプリケーションの新しいバージョンを検索します。 しかし、これは明示的にインストールされたものしか確かめません(そうしたアプリケーションは/var/lib/portage/worldにリストされています)。 つまり、それらの依存関係は確認しないということです。 明示的にインストールされたパッケージの依存も更新したいときには--deep引数を与えてやります。

コード表示 3.11: システムを依存関係を含めて更新する

# emerge --update --deep @world

これでも全てのパッケージが更新されるわけではありません。 システムにインストールされているパッケージの中にはコンパイルとビルドの間には必要ではあるものの、 インストールが終わってしまえばもう必要ないようなパッケージもあります。 Portageでは、そのようなパッケージをbuild dependencies (ビルド依存)と呼んでいます。 これを更新に含めるには--with-bdeps=yを追加します。

コード表示 3.12: システムの全てを更新する

# emerge --update --deep --with-bdeps=y @world

明示的にインストールしていない(だが他のプログラムの依存によりインストールされた)パッケージのセキュリティアップデートがあるかもしれないので、このコマンドを時々実行することが推奨されています。

もし最近USEフラグを変更したのなら、--newuseを追加したくなるでしょう。 そうするとPortageは新しいパッケージのインストールや既にインストールしたパッケージの再コンパイルが必要かを確認します。

コード表示 3.13: 完全な更新の実行

# emerge --update --deep --newuse --with-bdeps=y @world

メタパッケージ

Portageツリーのいくつかのパッケージには、それ自身は何のファイルもインストールしませんが、複数のパッケージをインストールするのに利用されるものがあります。 例えば、kde-metaパッケージは、依存関係にある様々なKDE関連のパッケージを制御することで、システムに完全なKDE環境をインストールします。

このようなパッケージをシステムから削除したいときには、emerge --unmergeをパッケージに対して実行しても依存関係が残ってしまうのでたいした効果は得られないでしょう。

Portageは残された依存関係を削除する機能性を持っていますが、動的に依存関係を変更するソフトウェアが存在するので、 USEフラグに変更を加えたときも含めてまずシステムを完全に更新する必要があります。 その後残された依存関係を削除するためにemerge --depcleanを実行してください。 これが完了したら、今削除されたソフトウェアを動的にリンクしているが、もはやそれを必要としないアプリケーションを再ビルドします。

これら全ては以下の3つのコマンドで処理できます。

コード表示 3.14: 残された依存関係を削除する

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

revdep-rebuildgentoolkitによって提供されます;まず最初にemergeすることを忘れないでください。

コード表示 3.15: gentoolkitパッケージのインストール

# emerge gentoolkit

1.d. ライセンス

Portage バージョン2.1.7から、ソフトウェアのライセンスをもとにして、ソフトウェアのインストール可否を制御できます。 Portageツリーにある全てのパッケージには、ebuildにLICENSE項目が含まれています。 emerge --search packagenameを実行すれば、パッケージのライセンスがわかります。

デフォルトでは、使用許諾契約書(EULA)に同意しなければならないものを除いて、Portageは全てのライセンスを許可します。

ACCEPT_LICENSEで許可するライセンスを制御します。これは、/etc/portage/make.confで設定されます。 次の例ではACCEPT_LICENSEのデフォルトを示しています。

コード表示 4.1: /etc/portage/make.confでACCEPT_LICENSEを設定する

ACCEPT_LICENSE="* -@EULA"

この設定により、インストール中に使用許諾契約に同意する行為が必要になるパッケージはインストールできなくなりますが、 その必要がないパッケージはインストールできるようになります。

ACCEPT_LICENSEはシステム全体では/etc/portage/make.confで設定可能です。 また、パッケージごとに/etc/portage/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-2.8ライセンスでのインストールは許可されません。

重要: 各ライセンスは/usr/portage/licensesに置かれ、ライセンスグループは/usr/portage/profiles/license_groupsに書かれています。 license_groupsの各行の一番初めの大文字で書かれた項目はライセンスグループの名前で、その後に個々のライセンスが書かれています。

ACCEPT_LICENSEで定義されたライセンスグループは、@記号が先頭につきます。 フリーソフトウェアとフリードキュメントだけをインストール可能にするという設定がよく使われています。 その設定を行なうには、全ての許容されているライセンスを(-*を使って)削除し、 FREEのグループのライセンスだけを以下のようにして許可します。

コード表示 4.3: フリーソフトウェアとフリードキュメントのライセンスだけを許可する/etc/portage/make.confの設定

ACCEPT_LICENSE="-* @FREE"

この場合の"フリー"とは、ほぼFSFOSIで定義されたものです。 これらの定義に合致しないライセンスを持つパッケージはインストールできません。

1.e. Portageが不満を言ったら

SLOT、Virtual、ブランチ、アーキテクチャ、そしてプロファイルについて

既に述べたように、Portageはとても強力で他のソフトウェア管理ツールに無い多くの機能をサポートしています。 このことを理解するために、あまり細かくなり過ぎるのを避けて、もう少しPortageの特徴について説明します。

Portageでは、同一のパッケージの異なるバージョンをシステム上に共存させることができます。 他のディストリビューションが(freetypefreetype2の様に)それらの名前にバージョンを付けているのに対し、 PortageはSLOTと呼ばれる技術を使っています。 ebuildはそのバージョンごとにSLOTを宣言します。SLOTが異なるebuildはシステム上で共存できます。 例えば、freetypeパッケージはSLOT="1"SLOT="2"のebuildを持っています。

同一の機能を提供する実装の異なるパッケージもまた存在します。 例えば、metalogdsysklogdsyslog-ngは全てシステムロガーです。 「システムロガー」の機能を必要とするアプリケーションは、例えばmetalogdに依存することはできません。他のシステムロガーも同様に問題のない選択だからです。 そこで、Portageは仮想パッケージを考慮に入れます。つまり、virtual/loggerには、それぞれのシステムロガーが"排他的な"依存関係になるように登録されるのです。 これにより、アプリケーションはvirtual/loggerなるパッケージに依存できるようになります。 まだシステムロガーがインストールされていない場合、この仮想パッケージは依存関係を満足するように、登録されている先頭のシステムロガーをインストールしようとします。

Portageツリーのソフトウェアは異なったブランチに所属することができます。 デフォルトではシステムはGentooがstableだと思うもののみ受け付けます。 ほとんどのコミットされた新しいソフトウェア名は、stableにされる前にもっとテストが必要だという意味のテストブランチに追加されます。 これらのソフトウェアのebuildをPortageツリーで見かけても、Portageはstableブランチに置かれるまでは更新しようとしないでしょう。

いくつかのソフトウェアは特定のアーキテクチャでのみ利用可能な場合があります。 すなわちそのソフトウェアは他のアーキテクチャでは動作しないか、もっとテストが必要か、 Portageツリーにソフトウェアをコミットした開発者が別のアーキテクチャで動作するかどうか確認できないかです。

各々のGentooのインストールはあるプロファイルに従っています。 プロファイルには、システムが正常に動作するために必要なパッケージのリストなどが含まれています。

ブロックされたパッケージ

コード表示 5.1: ブロックされたパッケージに対するPortageの警告(--pretendを利用)

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

コード表示 5.2: ブロックされたパッケージに対するPortageの警告(--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は、Portageにその依存関係についての情報を指示する特別なフィールドを含んでいます。 依存関係には2つの種類があります: DEPENDによって宣言されたビルド依存と、RDEPENDによって宣言された実行時依存です。 これらの依存関係で明示的に互換性のないパッケージまたはvirtualが指定されている場合、インストールがブロックされます。

Portageの最近のバージョンでは、些細なブロックについてはユーザーへの注意を促すことなく対処することができますが、 場合によっては、次に説明する方法でユーザー自身で解決しなければなりません。

ブロックを解決するには、パッケージのインストールを行わないか、衝突しているパッケージを先にunmergeするかのどちらかを選べます。 上記の例では、postfixのインストールを諦めるか、先にssmtpを削除するかのどちらかです。

<media-video/mplayer-1.0_rc1-r2.のように特定のパッケージ識別子(atom)を伴いブロックされていることがあるかもしれません。 この場合、ブロックしているパッケージをより新しいバージョンに更新すれば、ブロックを取り除くことができるかもしれません。

2つのパッケージがインストールしようとして、お互いをブロックし合っていることもあります。 このまれな場合には、何故それらをインストールする必要があるのかを調べてみてください。 ほとんどの場合、1つのパッケージのみで事足ります。 そうでなければ、Gentooのバグトラックシステムにバグを報告してください。

マスクされたパッケージ

コード表示 5.3: マスクされたパッケージに対するPortageの警告

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

コード表示 5.4: マスクされたパッケージに対するPortageの警告に関する理由

!!! 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)
- net-im/skype-2.1.0.81 (masked by: skype-eula license(s))

システムで利用できないパッケージをインストールしようとしたときに、このマスクエラーを受け取るでしょう。 システムで利用できる他のアプリケーションのインストールを試すか、パッケージが利用可能になるまで待ちましょう。 パッケージがマスクされているのにはいつも理由があります。

  • ~arch keyword はstableブランチに置くには十分なテストが行われていないことを意味します。 数日か数週間か待ってもう一度試してみてください。
  • -arch keyword-* keywordはあなたのアーキテクチャでは動作しないことを意味します。 もしパッケージが動作すると信じているならbugzillaにバグを提出してください。
  • missing keywordはあなたのアーキテクチャでは未だテストされていないことを意味します。 アーキテクチャのポーティングチームにテストするよう頼むか、自分でテストして気付いたことをbugzillaまで報告してください。
  • package.maskはパッケージが壊れている、不安定もしくは非推奨であるということが判明していて、意図的に利用禁止とマークされていることを意味します。
  • profileはあなたのプロファイルには適当ではないことを意味します。 インストールするとシステムを破壊するおそれがあるか、もしくは単にあなたのプロファイルと互換性がないかのどちらかです。
  • licenseはパッケージのライセンスがACCEPT_LICENSEと合致しないことを意味します。 /etc/portage/make.conf/etc/portage/package.licenseに設定することで、 明示的にそのライセンスかライセンスグループを許可しなければいけません。 詳しくは、ライセンスを参照してください。

必要なUSEフラグの変更

コード表示 5.5: PortageがUSEフラグの変更が必要との警告を出しています

The following USE changes are necessary to proceed:
#required by app-text/happypackage-2.0, required by happypackage (argument)
>=app-text/feelings-1.0.0 test

--autounmaskをつけていなければエラーメッセージは次のようになっているでしょう。

コード表示 5.6: Portageが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:
- app-text/feelings-1.0.0 (Change USE: +test)
(dependency required by "app-text/happypackage-2.0" [ebuild])
(dependency required by "happypackage" [argument])

こういった警告やエラーは、ただ単純に他のパッケージに依存しているだけでなく、 そのパッケージが特定のUSEフラグ(や、複数のUSEフラグの組みあわせ)でビルドされていることを必要とするパッケージをインストールする時に起こります。 上の例ではapp-text/feelingsUSE="test"でビルドされていなければいけませんが、 このUSEフラグはシステムで設定されていません。

これを解決するには/etc/portage/make.confでグローバルUSEフラグに追加するか、 または/etc/portage/package.useでパッケージごとのUSEフラグを設定してください。

依存関係の欠落

コード表示 5.7: 依存関係の欠落に対するPortageの警告

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.

インストールしようとしているアプリケーションはシステムで利用できない他のパッケージに依存しています。 bugzillaに既に報告されているか確認して、まだであれば報告してください。 ブランチを混ぜていない限りこれが起こることはありませんので、それはバグであると言えます。

曖昧なebuild名

コード表示 5.8: 曖昧なebuild名に対するPortageの警告

[ Results for search key : listen ]
[ Applications found : 2 ]

*  dev-tinyos/listen [ Masked ]
      Latest version available: 1.1.15
      Latest version installed: [ Not Installed ]
      Size of files: 10,032 kB
      Homepage:      http://www.tinyos.net/
      Description:   Raw listen for TinyOS
      License:       BSD

*  media-sound/listen [ Masked ]
      Latest version available: 0.6.3
      Latest version installed: [ Not Installed ]
      Size of: 859 kB
      Homepage:      http://www.listen-project.org
      Description:   A Music player and management for GNOME
      License:       GPL-2

!!! The short ebuild name "listen" is ambiguous. Please specify
!!! one of the above fully-qualified ebuild names instead.

インストールしようとしているアプリケーション名が2つ以上と一致しています。 正しいカテゴリー名も追加する必要があります。 Portageが(カテゴリー名をふくんだ)パッケージの候補を出力してくれます。

循環依存

コード表示 5.9: 循環依存に対するPortageの警告

!!! 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

2つ(もしくはそれ以上)のインストールしたいパッケージがお互いに依存し合っているためにインストールすることができません。 これはほとんどはPortageツリーのバグです。 bugzillaに既に報告されているか確認して、まだであれば報告してください。

取得失敗

コード表示 5.10: 取得失敗に対するPortageのエラー

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

Portageがアプリケーションのソースのダウンロードに失敗し、(可能であれば)他のアプリケーションのインストールを続けようとしています。 この失敗はミラーが正しく同期されていないか、ebuildが正しくない場所を示しているからかもしれません。 ソースを置いているサーバーが何らかの理由でダウンしているのかもしれません。

一時間程度空けて、もう一度確認してみましょう。

システムプロファイルによるパッケージの保護

コード表示 5.11: プロファイルによって保護されたパッケージに対するPortageの警告

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

あなたはシステムのコアの一部であるパッケージを削除しようとしました。 しかし、プロファイルで必須であるとされているので、システムから削除するべきではありません。

ダイジェストの検証失敗

ときどき、あるパッケージをemergeしようとして、次のようなメッセージと共に失敗することがあるかもしれません。

コード表示 5.12: ダイジェストの検証失敗

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

これはPortageツリーにどこかおかしい所がある兆候です。 よく、開発者がパッケージをツリーにコミットするとき失敗したことが原因で起こります。

ダイジェストの検証に失敗するとき、そのパッケージをあなた自身でダイジェストを再度作成しようとしてはいけません。 この問題はebuild foo manifestでは修正されない上に、ほぼ間違いなく悪化します。

かわりに、1時間か2時間ツリーが安定するのを待っていてください。 おそらくエラーはすぐに検知されると思いますが、修正がPortageツリーに流れるのに少し時間がかかります。 待っている間、Bugzillaをチェックし、誰かがこの問題をすでに報告しているか調べてください。 もし報告している人がいなければ、壊れているパッケージのバグ報告をしてください。

この問題が修正されたら、ダイジェストが修正されたツリーを再び同期しましょう。

重要: 何度もツリーの同期すれば良いという意味ではありません! rsyncポリシーで述べているように、必要以上にツリーの同期(emerge --sync)を行うユーザーは接続を禁止されます! もっとはっきり言えば、普段行っている頻度のまま次のツリーの同期まで我慢しましょう。 そうすれば、rsyncサーバーに余計な負荷をかけずに済みます。


[ << ] [ < ] [ ホーム ] [ > ] [ >> ]


印刷

全てを見る

ページの更新日 2013年 12月 17日

このドキュメントのオリジナルバージョン の更新日は2014年 8月 17日

要約: この章では、システムにおけるソフトウェアの管理をしていくのに、 ユーザーが知っておくべき手順を「簡単に」説明します。

Sven Vermeulen
Author

Roy Marples
Author

Daniel Robbins
Author

Chris Houser
Author

Jerry Alexandratos
Author

Seemant Kulleen
Gentoo x86 Developer

Tavis Ormandy
Gentoo Alpha Developer

Jason Huebel
Gentoo AMD64 Developer

Guy Martin
Gentoo HPPA developer

Pieter Van den Abeele
Gentoo PPC developer

Joe Kallar
Gentoo SPARC developer

John P. Davis
Editor

Pierre-Henri Jondot
Editor

Eric Stockbridge
Editor

Rajiv Manglani
Editor

Jungmin Seo
Editor

Stoyan Zhekov
Editor

Jared Hudson
Editor

Colin Morey
Editor

Jorge Paulo
Editor

Carl Anderson
Editor

Jon Portnoy
Editor

Zack Gilburd
Editor

Jack Morgan
Editor

Benny Chuang
Editor

Erwin
Editor

Joshua Kinard
Editor

Tobias Scherbaum
Editor

Xavier Neys
Editor

Grant Goodyear
Reviewer

Gerald J. Normandin Jr.
Reviewer

Donnie Berkholz
Reviewer

Ken Nowack
Reviewer

Lars Weiler
Contributor

おぎうち やすお
翻訳

わただ ゆうすけ
翻訳

せーいち
翻訳

五十嵐 正尚
翻訳

武田 洋之
翻訳

村上 誠
翻訳

小林 弘樹
翻訳

真藤 直観
翻訳

萩原 佳明
翻訳

松葉
翻訳

中野 正智
翻訳

飴谷 茂寛
翻訳

村上 卓
翻訳

田中 裕也
翻訳

増田 昌也
翻訳

Donate to support our development efforts.

Copyright 2001-2014 Gentoo Foundation, Inc. Questions, Comments? Contact us.