path: root/markup/pod/live-manual/media/text/ja/user_customization-packages.ssi

:B~ インストールするパッケージの独自化

1~customizing-package-installation インストールするパッケージの独自化

恐らく Live システムの最も基本的な独自化はイメージに収録するパッケージの選択でしょう。この章では live-build
でのパッケージのインストールの独自化のためのビルド時の様々なオプションを見ていきます。イメージへのインストールに利用可能なパッケージに関して最も影響が大きい選択はディストリビューションとアーカイブ領域です。まともなダウンロード速度を確保するため、近いディストリビューションミラーを選択してください。backports
や experimental
あるいは独自のパッケージのある自身専用のリポジトリを追加することもできます。また、ファイルを直接パッケージとして収録することもできます。特定のデスクトップや言語のパッケージ等、多数の関連パッケージを同時にインストールするメタパッケージを含め、パッケージ一覧は定義できます。最後に、ビルドでパッケージをインストールするときに
/{apt}/ や好みにより /{aptitude}/
を制御するオプションもいくらかあります。プロキシを使っていたり、推奨パッケージのインストールを無効にして容量を節約したい、インストールするパッケージのバージョンをAPTのピン経由で制御する必要がある、等便利だと思う場面があるかもしれません。

2~ パッケージソース

3~ ディストリビューション、アーカイブ領域とモード

ディストリビューションの選択は Live イメージへの収録に利用できるパッケージに最も影響があります。コード名を指定してください。${testing}
バージョンの live-build では ${testing}
がデフォルトになっています。現在アーカイブにある任意のディストリビューションをコード名で指定できます (詳細については{条件}#terms
参照)。#{--distribution}#
オプションはアーカイブ内のパッケージソースに影響するだけでなく、サポートしている各ディストリビューションをビルドするのに必要な動作をするよう
live-build に指示します。例えば*{unstable}*リリースであるsidに対してビルドする場合は:

code{

 $ lb config --distribution sid

}code

のように指定します。ディストリビューションアーカイブ内で、アーカイブ領域はアーカイブを大きく分類します。Debian
では#{main}#、#{contrib}#、#{non-free}# となっています。#{main}#に収録されるソフトウェアだけが Debian
ディストリビューションの一部であり、したがってそれがデフォルトとなっています。複数指定することもできます。例えば

code{

 $ lb config --archive-areas "main contrib non-free"

}code

Debian 派生物によっては #{--mode}# オプションの実験的サポートが利用できるものがあります。このオプションは Debian
または未知のシステムでビルドしている場合にのみデフォルトで #{debian}# がセットされています。サポートしている派生物のどれかで #{lb
config}# を実行した場合のデフォルト値はその派生物のイメージを作成するための値になります。#{lb config}# を例えば
#{ubuntu}# モードで実行すると Debian
向けに代えて指定された派生物のディストリビューション名やアーカイブ領域がサポートされます。このモードはその派生物に合うように live-build
の挙動も変更します。

*{注意:}* モードを追加したプロジェクトの設定については主にそのオプションのサポートユーザの担当です。${project}は最善の努力をもって開発サポートを提供はしますが、私たちは派生物を自ら開発あるいはサポートしているわけではないため、あくまで派生物プロジェクトからのフィードバックが基になります。

3~ ディストリビューションミラー

Debian
アーカイブは世界中の巨大なネットワークミラーにまたがって複製されているため、各地域の人が最高のダウンロード速度を求めて近いミラーを選択できます。#{--mirror-*}#
オプションはそれぞれ、ビルドの様々な段階でどのディストリビューションミラーを利用するのかを決定します。{ビルド段階}#stages-of-the-build
の繰り返しになりますが*{パッケージ収集}*段階は最小限のシステムで /{debootstrap}/ により最初に chroot
を構成する段階、*{chroot}* 段階は chroot を使って Live
システムのファイルシステムをビルドする段階です。ミラーはこの各段階ごとにそれぞれのオプションで指定するため*{バイナリ}*の段階では
#{--mirror-binary}# や #{--mirror-binary-security}#
の値が採用され、早い段階で使っていたミラーは置き換えられることになります。

3~distribution-mirrors-build-time ビルド時に利用するディストリビューションミラー

ビルド時に利用するディストリビューションミラーにローカルミラーを指定するには、#{--mirror-bootstrap}# と
#{--mirror-chroot-security}# を以下のように指定するだけです。

code{

 $ lb config --mirror-bootstrap http://localhost/debian/ \
          --mirror-chroot-security http://localhost/debian-security/

}code

#{--mirror-chroot}# で指定する chroot ミラーのデフォルト値は #{--mirror-bootstrap}#
の値になっています。

3~ 実行時に利用するディストリビューションミラー

#{--mirror-binary*}# オプションはバイナリイメージ中のディストリビューションミラーの位置を決定します。このオプションは Live
システムの実行中に追加のパッケージをインストールする際に利用できます。デフォルトは #{httpredir.debian.org}#
で、利用できるミラーの中から特にユーザのIPアドレスを基にして地理的に近いミラーを選択するサービスになっています。これはその Live
システムを利用するユーザにとって最適なミラーを予測できない場合に適切な選択です。以下の例に示すように自分専用の値を指定することもできます。この設定でビルドされたイメージはその"#{ミラー}#"が到達可能なネットワークにいるユーザにとってのみ適します。

code{

 $ lb config --mirror-binary http://mirror/debian/ \
          --mirror-binary-security http://mirror/debian-security/ \
          --mirror-binary-backports http://mirror/debian-backports/

}code

3~additional-repositories 追加リポジトリ

リポジトリをさらに追加して、利用できるパッケージ選択の幅を対象ディストリビューション以外にも広げられます。それにより、例えば backports や
experimental、そして独自のパッケージを利用できます。追加のリポジトリを設定するには
#{config/archives/your-repository.list.chroot}# や
#{config/archives/your-repository.list.binary}# ファイルを作成します。#{--mirror-*}#
オプションにより、イメージのビルドの *{chroot}* 段階や*{バイナリ}*段階、つまり Live
システムの実行時に利用するリポジトリを決定できます。

例えば #{config/archives/live.list.chroot}# により Live システムのビルド時に debian-live
スナップショットリポジトリからパッケージをインストールできます。

code{

 deb http://live-systems.org/ sid-snapshots main contrib non-free

}code

同一の行を #{config/archives/live.list.binary}# に追加すると、Live システムの
#{/etc/apt/sources.list.d/}# ディレクトリにそのリポジトリが追加されます。

こういったファイルが存在すれば自動的に処理されます。

リポジトリの署名に利用されたGPG鍵を #{config/archives/your-repository.key.{binary,chroot}}#
ファイルに置くこともできます。

APTのピン止めが独自に必要な場合、APT設定行等を
#{config/archives/your-repository.pref.{binary,chroot}}# ファイルに配置すれば自動的に Live
システムの #{/etc/apt/preferences.d/}# ディレクトリに追加されます。

2~choosing-packages-to-install インストールするパッケージの選択

There are a number of ways to choose which packages live-build will install
in your image, covering a variety of different needs. You can simply name
individual packages to install in a package list. You can also use
metapackages in those lists, or select them using package control file
fields. And finally, you may place package files in your #{config/}# tree,
which is well suited to testing of new or experimental packages before they
are available from a repository.

3~package-lists パッケージ一覧

パッケージ一覧はインストールするパッケージを明確にする強力な方法です。一覧の構文では条件付けをサポートし、一覧の生成や複数の設定への適合を容易にしています。ビルド時にシェルヘルパーを使って一覧にパッケージ名を差し込むこともできます。

*{注意:}* 存在しないパッケージが指定されたときの live-build の挙動はAPTユーティリティの選択により決定されます。さらなる詳細については {apt と aptitude の選択}#choosing-apt-or-aptitude を見てください。

3~using-metapackages メタパッケージの利用

パッケージ一覧を指示するもっとも簡単な方法は利用するディストリビューションで保守されているタスクのメタパッケージの利用です。例えば:

code{

 $ lb config
 $ echo task-gnome-desktop > config/package-lists/desktop.list.chroot

}code

#{live-build}# 2.x
でサポートされていた、一覧を事前定義する古い方法はこれで置き換えられました。一覧の事前定義とは異なり、タスクのメタパッケージは Live
システムプロジェクト特有のものではありません。タスクのメタパッケージはディストリビューション内の専門の作業グループにより保守されているため、要求したユーザに対して提供する最善のパッケージについて、各グループでの合意を反映したものとなっています。また、一覧を事前定義する置き換えられた方法よりはるかに幅広い事例にも対応できます。

タスクのメタパッケージには全て先頭が #{task-}# から始まるため、利用できるものを簡単に判別する方法があります
(名前が該当しても実際にはメタパッケージではないものもほんの一部とはいえありますが)。パッケージ名を前方一致で検索します:

code{

 $ apt-cache search --names-only ^task-

}code

以上に加え、他に様々な目的を持ったメタパッケージを見つけられるでしょう。#{gnome-core}#
のように他のもっと範囲の広いタスクパッケージの一部を構成するものや、#{education-*}# メタパッケージのように Debian Pure
Blend の中のある個々の専門分野に特化したものもあります。アーカイブにある全メタパッケージを列挙するには、#{debtags}#
パッケージをインストールして #{role::metapackage}# タグの付けられたパッケージを全て列挙させます:

code{

 $ debtags search role::metapackage

}code

3~ ローカルパッケージ一覧

列挙したものがメタパッケージであれ、個々のパッケージであれ、両方の組み合わせであれ、ローカルパッケージ一覧は全て
#{config/package-lists/}#
に保存されます。この一覧は複数利用できるため、うまい具合にこの一覧自体を組み込める設計になっています。例えばある一覧は特定のデスクトップ選択時向け、別の一覧は異なるデスクトップでも簡単に使えるような関連パッケージ群を、というようにできます。これにより、パッケージ群の異なる組み合わせを最小限の手間で試したり、あるいは異なる
Live イメージプロジェクトで一覧を共有する、といったことが可能になります。

このディレクトリに存在するパッケージ一覧は、処理対象とするためには後ろに #{.list}#
を付ける必要があり、さらにその一覧をどの段階の対象とするのか示すためには #{.chroot}# や #{.binary}# をその後に追加します。

*{注意:}* 対象とする段階の指定を追加しない場合、その一覧は両方の段階で利用されます。通常指定するのは #{.list.chroot}# で、この場合そのパッケージは Live ファイルシステムにのみインストールされ、メディア上に #{.deb}# の余計なコピーは置かれません。

3~ ローカルバイナリパッケージ一覧

バイナリ段階の一覧を作成する場合はファイルの末尾を #{.list.binary}# にして #{config/package-lists/}#
に置きます。それにより指定したパッケージは Live ファイルシステムにはインストールされず、Live メディアの #{pool/}#
以下に収録されます。Live ではないインストーラでこういった一覧を標準的に利用しているものもあります。バイナリ段階で chroot
段階と同一の一覧を利用したい場合は上述したように末尾を #{.list}# とします。

3~generated-package-lists 生成されたパッケージ一覧

一覧の構成はスクリプトで生成するのが最善の方法だということもあります。感嘆符から始まる行は全て、そのコマンドがイメージのビルド後に chroot
内で実行されることを示します。例えばパッケージ一覧に #{! grep-aptavail -n -sPackage -FPriority
standard | sort}# という行を書いておけば、#{Priority: standard}#
で利用可能なパッケージをソートした一覧を生成できます。

実際、パッケージの選択に #{grep-aptavail}# コマンド (#{dctrl-tools}# パッケージに収録)
はとても有用なので、#{live-build}# では便宜のため #{Packages}#
補助スクリプトを提供しています。このスクリプトは引数を#{フィールド}#と#{パターン}#の2つ取ります。一覧を作成する例:

code{

 $ lb config
 $ echo '! Packages Priority standard' > config/package-lists/standard.list.chroot

}code

3~ 条件付き内部パッケージ一覧の利用

#{config/*}# (#{LB_}# が先頭に付くものは除く) に保存された live-build
の設定変数はどれもパッケージ一覧の条件文で利用できます。一般には #{lb config}#
オプションを大文字に、ダッシュ文字をアンダースコアに変更したものになります。しかし実際に意味があるのは、パッケージ選択に関わるもの、例えば
#{DISTRIBUTION}# や #{ARCHITECTURES}#、#{ARCHIVE_AREAS}# だけです。

例えば #{--architectures amd64}# が指定された場合に #{ia32-libs}# をインストールする場合:

code{

 #if ARCHITECTURES amd64
 ia32-libs
 #endif

}code

任意の1つを条件の値とすることもできます。#{--architectures i386}# または #{--architectures amd64}#
のどちらかが指定された場合に /{memtest86+}/ をインストールする場合の例:

code{

 #if ARCHITECTURES i386 amd64
 memtest86+
 #endif

}code

値を複数指定できる変数を条件にすることもできます。#{--archive-areas}# で #{contrib}# または #{non-free}#
のどちらかが指定されている場合に /{vrms}/ をインストールする場合の例:

code{

 #if ARCHIVE_AREAS contrib non-free
 vrms
 #endif

}code

入り組んだ条件分岐はサポートしていません。

% FIXME:

3~ インストール時のパッケージの削除

#{config/package-lists}# ディレクトリの末尾が #{.list.chroot_live}# や
#{.list.chroot_install}# のファイルにパッケージを列挙できます。Live
用とインストール用の両方の一覧が存在する場合、#{.list.chroot_live}# に列挙されているパッケージは
(ユーザがインストーラを利用している場合) インストール後にフックにより削除されます。#{.list.chroot_install}#
に列挙されているパッケージは Live システムとインストールされたシステムの両方に存在することになります。これはインストーラ向けの特別な調整で、設定で
#{--debian-installer live}# をセットしている場合や Live
システム特有のパッケージをインストール時には削除したい場合に有用かもしれません。

3~desktop-and-language-tasks デスクトップ及び言語タスク

デスクトップと言語のタスクは特別で、計画性や設定が追加で必要となります。Live イメージが Debian
インストーライメージとは異なる点です。Debian
インストーラでは、特定のデスクトップ環境向けに用意されたメディアでは対応するタスクは自動的にインストールされます。内部に
#{gnome-desktop}# や #{kde-desktop}#、#{lxde-desktop}#、#{xfce-desktop}#
タスクがあり、#{tasksel}#
のメニューにはどれも出てきません。同様に言語向けタスクのメニュー項目はありませんが、インストール中にユーザが選択した言語が対応する言語タスクの選択に影響します。

デスクトップ向け Live イメージ開発時には、イメージは通常動作するデスクトップを直接ブートし、デスクトップやデフォルト言語はどちらも Debian
インストーラの場合のように実行時に選択するのではなくビルド時に決められています。これは Live
イメージでデスクトップや言語を複数サポートしてユーザに選択の機会を与えるようにできないわけではなく、それが live-build
のデフォルトの挙動ではないというだけです。

言語特有のフォントや入力メソッドにどのパッケージを収録するのか、といった規定は言語タスクにはないので、特定のパッケージを収録したい場合は設定で指定する必要があります。ドイツ語サポートを収録した
GNOME デスクトップイメージの場合に収録するタスクのメタパッケージの例:

code{

 $ lb config
 $ echo "task-gnome-desktop task-laptop" >> config/package-lists/my.list.chroot
 $ echo "task-german task-german-desktop task-german-gnome-desktop" >> config/package-lists/my.list.chroot

}code

3~kernel-flavour-and-version カーネルのフレーバー (種類) とバージョン

アーキテクチャによっては、イメージに複数のカーネルをデフォルトで収録することができます。フレーバーは #{--linux-flavours}#
オプションで選択できます。各フレーバーはデフォルトの短い #{linux-image}#
に、イメージに収録される実際のカーネルパッケージに依存する各メタパッケージの名前を付加した形式になります。

そうして、デフォルトで #{amd64}# アーキテクチャのイメージは #{linux-image-amd64}#
のメタパッケージを収録し、#{i386}# アーキテクチャのイメージは #{linux-image-586}# メタパッケージを収録します。

設定したアーカイブで複数バージョンのカーネルパッケージが利用できる場合、#{--linux-packages}#
オプションでカーネルパッケージ名の前半部を指定できます。例えば #{amd64}# アーキテクチャのイメージをビルドする際にテスト用に
experimental アーカイブを追加すると #{linux-image-3.18.0-trunk-amd64}#
カーネルをインストールできます。そのイメージの設定例:

code{

 $ lb config --linux-packages linux-image-3.18.0-trunk
 $ echo "deb http://ftp.debian.org/debian/ experimental main" > config/archives/experimental.list.chroot

}code

3~custom-kernels 独自のカーネル

Debian パッケージ管理システムに組み入れられていれば、独自のカーネルを自分でビルド、収録できます。live-build システムは
#{.deb}# パッケージでビルドされていないカーネルはサポートしていません。

自身のカーネルパッケージを配置するための適切で推奨する方法は #{kernel-handbook}#
の指示に従うことです。パッケージ名のABIとフレーバーの部分を忘れずに適切に変更し、リポジトリに #{linux}# の完全なビルドとそれに該当する
#{linux-latest}# パッケージを収録してください。

該当するメタパッケージ無しでカーネルパッケージをビルドしたい場合は、{カーネルのフレーバー (種類)
とバージョン}#kernel-flavour-and-version で説明しているように #{--linux-packages}#
でパッケージ名の適切な前半部を指定する必要があります。{変更したあるいはサードパーティ製パッケージのインストール}#installing-modified-or-third-party-packages
で説明しているように、自身のリポジトリに独自のカーネルパッケージを収録する場合はそのようにするのが最善ですが、別の方法についても説明しています。

カーネルを独自化する方法はこの文書の対象範囲ではありません。とはいえ、設定が最低限満たさないといけない要件があります:

_* 初期RAMディスクを利用する。

_* 結合ファイルシステムモジュール (つまり通常は #{aufs}#) を収録する。

_* 自分の設定で必要とする他のファイルシステムモジュール (つまり通常は #{squashfs}#) があればそれを収録する。

2~installing-modified-or-third-party-packages 変更したあるいはサードパーティ製パッケージのインストール

Live システムの哲学には反しますが、Debian リポジトリにあるバージョンのパッケージを改変して Live
システムをビルドする必要に迫られることもあります。それは機能や言語、商標を変更あるいは追加するものであったり、既存のパッケージから望ましくない要素を削除するものであるかもしれません。同様に求める機能や独自開発の機能を追加するのに「サードパーティ製」パッケージを利用できます。

この節では変更したパッケージのビルドや保守については対象としていません。Joachim Breitner さんの
http://www.joachim-breitner.de/blog/archives/282-How-to-fork-privately.html
にある「How to fork privately」に書かれている方法が該当するのかもしれませんが。求める機能を収録したパッケージの作成については
https://www.debian.org/doc/maint-guide/ にある Debian 新メンテナーガイドその他で説明されています。

変更した独自のパッケージをインストールする方法は2つあります:

_* #{packages.chroot}#

_* 独自APTリポジトリの利用

#{packages.chroot}#
を使う方法はより簡単に出来て「一度限りの」独自化には有用ですが欠点がいくつかあります。一方独自のAPTリポジトリを使う方法はその準備に時間がかかりまます。

3~ #{packages.chroot}# を利用した独自のパッケージのインストール

独自化したパッケージをインストールするには、単に#{config/packages.chroot/}#
ディレクトリにコピーします。このディレクトリ内に置かれたパッケージはビルドの際に Live システムに自動的にインストールされます -
他のどこかを指定する必要はありません。

パッケージ名は規定の命名規則に従わ*{ないといけません}*。それを簡単に行う方法は #{dpkg-name}# の利用です。

#{packages.chroot}# を利用した独自のパッケージのインストールには欠点があります:

_* secure APT を利用することができません。

_* #{config/packages.chroot/}# ディレクトリに適切なパッケージを全てインストールしないといけません。

_* Live システムの設定をリビジョン管理するには適しません。

3~ APTリポジトリを利用した独自パッケージのインストール

#{packages.chroot}#
を使う場合とは異なり、独自のAPTリポジトリを使う場合は他のどこかでパッケージを指定する必要があります。詳細については{インストールするパッケージの選択}#choosing-packages-to-install
を見てください。

独自のパッケージをインストールするためにAPTリポジトリを作成するのは不要な手間だと思うかもしれませんが、その基盤は変更したパッケージを後で更新する際に簡単に再利用できます。

3~ 独自パッケージとAPT

live-build は Live
システムへのパッケージのインストールに全てAPTを利用するため、そのプログラムの挙動を引き継ぎます。関連する一例としては
(デフォルト設定だと仮定して)、異なる2つのリポジトリでバージョン番号の異なるあるパッケージが利用可能な場合に、APTはバージョン番号の大きい方のパッケージをインストールに選択します。

そのため、独自パッケージの #{debian/changeLog}# ファイルでバージョン番号を増加させ、公式の Debian
リポジトリにあるものよりも変更したバージョンが確実にインストールされるようにすると良いでしょう。Live
システムのAPTのピン設定を改変する方法もあります - さらなる情報については、{APTのピン止め}#apt-pinning を見てください。

2~ ビルド時のAPT設定

ビルド時だけに適用されるオプションを使ってAPTを設定できます (実行中の Live システムで利用されるAPTの設定は Live
システムの内容による通常の、#{config/includes.chroot/}# で適切な設定を収録する)
方法により設定できます。オプションの全容については #{lb_config}# man ページの #{apt}# で始まるオプションを見てください。

3~choosing-apt-or-aptitude apt と aptitude の選択

ビルド時にパッケージをインストールする際に /{apt}/ と /{aptitude}/ のどちらを利用するのか選択できます。利用するユーティリティは
#{lb config}# の #{--apt}#
引数で決定します。パッケージが欠けている場合の処理方法に顕著な違いがあることに着目し、パッケージのインストール時に望ましい挙動を実装している方を選択してください。

_* #{apt}#: この方法では、欠けているパッケージが指定された場合にそのパッケージのインストールは失敗します。これはデフォルトの設定です。

_* #{aptitude}#: この方法では、欠けているパッケージが指定された場合にそのパッケージのインストールは成功します。

3~ APTでのプロキシの利用

よく要求されるAPTの設定として、プロキシの内側でのイメージのビルドへの対応があります。必要に応じて、#{--apt-ftp-proxy}# や
#{--apt-http-proxy}# オプションによりAPTプロキシを指定できます。例:

code{

 $ lb config --apt-http-proxy http://proxy/

}code

3~tweaking-apt-to-save-space APTの調整による容量節約

イメージのメディアの容量をいくらか節約する必要があるかもしれません。その場合は以下に挙げるオプションを利用するといいかもしれません。

APTの索引をイメージに収録したくない場合は除外できます:

code{

 $ lb config --apt-indices false

}code

これは #{/etc/apt/sources.list}# 内の項目には影響せず、単に #{/var/lib/apt}#
に索引ファイルを収録するかどうかだけに影響します。その代わりに、Live システムでAPTを操作するためにはこの索引が必要なので、#{apt-cache
search}# や #{apt-get install}# を実行する前にユーザは例えば #{apt-get update}#
をまず実行して索引を作成しないといけません。

推奨パッケージのインストールによりイメージが肥大化しているような場合、以下で説明している影響を踏まえた上でAPTのデフォルトオプションを無効にできます:

code{

 $ lb config --apt-recommends false

}code

推奨パッケージを無効にした場合の最も重要な影響は、#{live-boot}# や #{live-config}# 自体が、ほとんどの Live
設定に利用している重要な機能を提供する一部のパッケージを推奨していることによるもので、例えば #{live-config}# が推奨し、Live
ユーザの作成に利用している #{user-setup}#
があります。ほぼ例外なく、パッケージ一覧に追加しないといけないパッケージが推奨パッケージの中にいくらかあります。追加しない場合は、イメージが期待通りに動作しないということになります。ビルドに収録されている各
#{live-*}# パッケージの推奨パッケージを確認し、省略できると確信できない場合はパッケージ一覧に当該パッケージを追加するようにしてください。

あるパッケージの推奨パッケージをインストールしないことによるもっと一般的な影響は「異常なインストール状態でなければあるパッケージとともにあるはずの」(Debian
ポリシーマニュアル7.2節) Live
システムのユーザが実際に必要とする一部のパッケージが省略されているかもしれないということです。したがって、推奨パッケージのインストールを無効にした場合とのパッケージ一覧
(#{lb build}# により生成される #{binary.packages}# ファイル参照)
の違いを確認して、欠けているパッケージの中にインストールしたいものがあれば一覧に収録することを推奨しています。推奨パッケージからほんの一部を除外したい場合は、推奨パッケージのインストールは有効なままにしておき、{APTのピン止め}#apt-pinning
で説明しているようにAPTのピン機能で、選択したパッケージについて負の優先度をセットしてインストールされないようにする方法があります。

3~ apt や aptitude へのオプションの受け渡し

障害となるAPTの挙動を変更するための #{lb config}# オプションがない場合、#{--apt-options}# や
#{--aptitude-options}# により任意のオプションを選択したAPTツールに渡せます。詳細については #{apt}# や
#{aptitude}# の man
ページを見てください。どちらのオプションにも、優先設定に加えて保持しておく必要のあるデフォルト値があることに注意してください。そのため、例えば
#{snapshot.debian.org}# からテスト用に何か取得する場合に
#{Acquire::Check-Valid-Until=false}# を指定するとAPTは古いままの #{Release}#
ファイルを使い続けます。以下の例のように、デフォルト値 #{--yes}# の後に新しいオプションを付加します:

code{

 $ lb config --apt-options "--yes -oAcquire::Check-Valid-Until=false"

}code

このオプションを利用する場合は man
ページを確認して完全に理解するようにしてください。これはあくまで例であり、イメージをこの方法で設定するようにという助言だと解釈することのないようにしてください。このオプションは例えば
Live イメージの最終的なリリースには適しません。

#{apt.conf}# のオプションを利用するようなもっと複雑なAPT設定には代わりに #{config/apt/apt.conf}#
ファイルを作成すると良いでしょう。少数ですが、よく必要とされるオプションへの有用なショートカットがあります。他の #{apt-*}#
オプションについても参照してください。

3~apt-pinning APTのピン止め

背景として、#{apt_preferences(5)}# man
ページをまず読んでください。APTのピン機能はビルド時用と実行時用に設定できます。前者については
#{config/archives/*.pref}#、#{config/archives/*.pref.chroot}#、#{config/apt/preferences}#
を、後者については #{config/includes.chroot/etc/apt/preferences}# を作成してください。

${testing} の Live システムをビルドするとしましょう。その場合に必要な Live パッケージは全て、ビルド時にバイナリイメージを sid
からインストールする必要があります。APTソースに sid を追加して、ピン機能で sid の Live
パッケージには高い優先度をセットし、他のパッケージには全てデフォルトよりも低い優先度をセットする必要があります。そうするとビルド時に望むパッケージだけを
sid からインストールし、他は全て対象システムのディストリビューションである ${testing} から取得します。以下によりその動作になります:

code{

 $ echo "deb http://mirror/debian/ sid main" > config/archives/sid.list.chroot
 $ cat >> config/archives/sid.pref.chroot << EOF
 Package: live-*
 Pin: release n=sid
 Pin-Priority: 600

 Package: *
 Pin: release n=sid
 Pin-Priority: 1
 EOF

}code

別のパッケージにより推奨されたパッケージを望まない場合に、ピン機能で優先度に負の値をセットすることによりそのパッケージをインストールしないようにできます。#{config/package-lists/desktop.list.chroot}#
で #{task-lxde-desktop}# を使って LXDE イメージをビルドしていて、wifi
パスワードをキーリングに保存するかユーザに聞かないようにしたいと仮定しましょう。このメタパッケージは /{lxde-core}/
に依存し、/{lxde-core}/ は /{gksu}/ を推奨し、/{gksu}/ は /{gnome-keyring}/
を推奨しています。そこで、推奨された /{gnome-keyring}/
パッケージを除外したい場合、#{config/apt/preferences}# に以下を追加することで除外できます:

code{

 Package: gnome-keyring
 Pin: version *
 Pin-Priority: -1

}code