第2章 Debian パッケージ管理

Debian システム上でのパッケージ設定の要点を次に記します。

	注意
	あなたの業務サーバーには、セキュリティー更新をした安定版 stable スイーツを推薦します。管理に限られた時間しか割けないデスクトップ PC に関しても同様の事が言えます。

私が上記のような警告をしても、多くの本文書の読者は、テスト版 testing や不安定版 unstable スイーツを使いたいと考えるのは分かっています。

Debian は以下の理由で 100% フリーソフトウェアーです:

一部の人は以下の2つの事実が矛盾するのでは無いかとの疑問を持ちます。

Debian システムはコントロールファイル中のバージョン情報付きのバイナリー依存関係宣言を通して整合性のあるバイナリーパッケージの集合を提供します。ここにその少々簡素化し過ぎの定義を示します。

	注記
	合理的な設定として "Provides" と "Conflicts" と "Replaces" とを単一バーチャルパッケージに対し同時宣言することが合理的な設定であることを承知下さい。こうするといかなる時にも当該バーチャルパッケージを提供する実パッケージのうち確実に一つだけがインストールされます。

パッケージ管理の簡略化されたイベントの流れをまとめると以下のようになります。

2つ以上の似たパッケージに出会い "試行錯誤" の努力無しにどのパッケージをインストールするか迷った際には、常識を使って下さい。次に示す点は好ましいパッケージの良い指標と考えます。

Debian は分散型の開発モデルのボランティアプロジェクトですので、そのアーカイブには目指すところや品質の異なる多くのパッケージがあります。これらをどうするかは自己判断をして下さい。

どのスイートの Debian システムを使うと決めようと、そのスイートで利用可能となっていないプログラムのバージョンをなんとか実行したいかもしれません。そのようなプログラムのバイナリーパッケージが他の Debian スイートとか他の非 Debian リソースで見つかるかもしれませんが、あなたの現行の Debian システムはそれらの要求条件と相容れないかもしれません。

aptitude は筆者が主に使う非常に良いインタラクティブツールではありますが、注意すべき事実があることを知っておくべきです。

apt(8) や aptitude(8) や apt-get(8) /apt-cache(8) を使うコマンドラインによるパッケージ管理操作を次に記します。

apt / apt-get と aptitude は大きな問題なく混用が可能です。

"aptitude why regex" は "aptitude -v why regex" とすることで、さらに詳しい情報を表示します。同様の情報は "apt rdepends package" や "apt-cache rdepends package" とすることでも得られます。

aptitude コマンドが最初コマンドラインモードで実行されパッケージ間のコンフリクトのような問題に直面した場合は、プロンプトがでた際に "e" を押すことでフルスクリーンのインタラクティブモードに切り替えられます。

	注記
	aptitude コマンドはその拡張されたパッケージリゾルバーのような豊富な機能が同梱されていますが、この複雑さは Bug #411123 や Bug #514930 や Bug #570377 のようないくつかのリグレッションを引き起こしました (また起こしているかもしれません)。疑義のある場合には、aptitude コマンドに代えて apt や apt-get や apt-cache コマンドを使って下さい。

"aptitude" のすぐ後ろにコマンドオプションをつけられます。

詳細は aptitude(8) や "/usr/share/doc/aptitude/README" にある "aptitude user's manual" を参照下さい。

インタラクティブなパッケージ管理のためには aptitude をインタラクティブモードでコンソールのシェルプロンプトから以下のように立ち上げます。

$ sudo aptitude -u
Password:

これによりアーカイブ情報のローカルコピーは更新され、フルスクリーンのパッケージリストがメニュー付きで表示されます。Aptitude の設定ファイルは "~/.aptitude/config" にあります。

	ヒント
	user の設定ファイルでなく root の設定ファイルを使いたい際には、上記の例で "sudo aptitude ..." の代わりに "sudo -H aptitude ..." を使います。

	ヒント
	Aptitude はインタラクティブに起動されると次にするアクションを自動的に設定します。その設定が好ましくない場合はメニュー:"Action" → "Cancel pending actions" からリセットすることができます。

パッケージの状態を閲覧し、"予定のアクション" の設定をこのフルスクリーンモードで各パッケージするための重要なキーを次に記します。

コマンドラインのファイル名の規定や、"l" や "//" を押した後のメニュープロンプトは次に記す aptitude の regex (正規表現) が使われます。aptitude の regex は "~n" で始めそれにパッケージ名を続けた文字列を使うことで明示的にパッケージ名とマッチさせられます。

	ヒント
	ビジュアルインターフェースで全てのインストール済みパッケージを候補バージョンにアップグレードさせるには "U" を押さなければいけません。これをしないと選ばれたパッケージとそれにバージョン付きの依存関係のある特定のパッケージのみが候補バージョンにアップグレードされます。

インタラクティブなフルスクリーンモードの aptitude(8) はパッケージリスト中のパッケージは以下の例のように表示されます。

idA   libsmbclient                             -2220kB 3.0.25a-1  3.0.25a-2

上記の行は左から次に記すような意味です。

	ヒント
	"?" を押して表示されるヘルプスクリーンの一番下に全フラグのリストがあります。

	注記
	パッケージの debtags によるタグ付け状況を改善するのにご協力下さい！

標準 "パッケージ画面" はパッケージを dselect にいくつかの機能を加えた感じで分類します。

Aptitude はその regex 式機能を通してパッケージを探索する方法をいくつか提供します。

	ヒント
	package_name という文字列は、"~" で始めて regex 式と明示されていない限り、パッケージ名との完全な一致検索として扱います。

	ヒント
	regex_pattern がヌル文字列の場合は "~T" をコマンドの直後に使って下さい。

次がショートカットです。

mutt が表現のお手本なので、mutt に慣れているユーザーはすぐ慣れるでしょう。"User's Manual" ("/usr/share/doc/aptitude/README") 中の "SEARCHING, LIMITING, AND EXPRESSIONS" を参照下さい。

	注記
	lenny バージョンの aptitude(8) では、新規の "?broken" のような長形式の regex マッチ形式が、古い "~b" のような短形式のマッチ形式に代えて使えます。そのためチルダ文字 "~" に加えてスペース文字 " " も regex の終端文字として扱われます。新規の長形式のマッチ形式については "User's Manual" を参照下さい。

aptitude によるパッケージの選択は、"F10 → Options → Preferences → Dependency handling" のメニュー設定に従って、"Depends:" リストに規定されたパッケージばかりでは無く "Recommends:" リストに規定されたパッケージも引き込みます。このような自動的にインストールされたパッケージは不要になると aptitude が自動的に削除します。

aptitude コマンドの"自動インストール" 挙動を制御するフラグは apt パッケージ中の apt-mark(8) コマンドを用いても操作できます。

パッケージ活動履歴はログファイルで確認できます。

パッケージの説明や "Tasks" の下のリストを使ってあなたが必要なパッケージを aptitude で見つけることができます。

以下のコマンドはパッケージの名前が regex にマッチするパッケージをリストします。

$ aptitude search '~n(pam|nss).*ldap'
p libnss-ldap - NSS module for using LDAP as a naming service
p libpam-ldap - Pluggable Authentication Module allowing LDAP interfaces

これはパッケージの正確な名前を探すときに非常に便利です。

"平坦なパッケージリスト" のビューで "l" のプロンプトに regex "~dipv6" を入れるとその意味にマッチするパッケージにビューが制限され、その情報をインタラクティブに閲覧できます。

削除したパッケージが残した全ての設定ファイルを以下のようにして完全削除できます。

以下のコマンドの結果をチェックします。

# aptitude search '~c'

もしリストされたパッケージが完全削除されても問題ないなら、以下のコマンドを実行します。

# aptitude purge '~c'

同様のことをインタラクティブにすればよりきめの細かい結果が得られます。

"新規パッケージ画面" のビューで "l" のプロンプトに regex "~c" を入れると regex にマッチする "削除されたが完全駆除されていない" パッケージにビューが制限されます。トップレベルの見出しの上で "[" を押すと regex にマッチする全てのパッケージが表示されます。

次に "インストールされていないパッケージ" 等のトップレベルの見出しの上で "_" を押します。その見出しの下の regex にマッチするパッケージだけが完全削除と設定されます。インタラクティブに個々のパッケージの上で "=" を押せばそれらのパッケージを完全削除対象から外せます。

このテクニックは非常に便利で、他の多くのコマンドキーでも使えます。

(非 aptitude のパッケージインストーラー等を使った後で) パッケージの自動 / 手動インストールの状態を整理する私の方法を次に記します。

"Tasks" の上で "m" を押すのも一案で、大量ファイル除去となる事態が回避できます。

	注記
	新規リリース等への移行は、Debian では下記のようにアップグレードできるのですが、新たなシステムをクリーンインストールすることを考えるべきです。こうすると溜めてきたゴミの除去ができる上に最新のパッケージの最良の組み合わせも分かります。もちろん安全な場所に完全なシステムのバックアップ (「バックアップと復元」を参照下さい) を事前にしなくてはいけません。異なったパーティションを使ったデュアルブート設定をすることをスムーズな移行をするためにお薦めします。

ソースリストの内容を新規リリースへ向けるように変更し、"apt update; apt dist-upgrade"コマンドを実行することでシステム全体のアップグレードができます。

aptitude ではハイレベル過ぎるとか必要な機能を欠くという他のパッケージ管理操作のリストです。

	注記
	multi-arch 機能のあるパッケージに関して、一部のコマンドはアーキテクチャー名を必要があるかもしれません。例えば、amd64 アーキテクチャーの libglib2.0-0 パッケージの内容をリストするには "dpkg -L libglib2.0-0:amd64" を使います。

	注意
	"dpkg -i …" や "debi …" といった低いレベルのパッケージツールはシステム管理者によって注意深く使われなければいけません。必要なパッケージ依存関係を自動的に面倒見てくれません。Dpkg の "--force-all" や類似のコマンドラインオプション (dpkg(1) 参照下さい) はエキスパートだけが使うようにできています。十分にその影響を理解せずに使うとシステム全体を壊してしまうかもしれません。

以下を承知下さい。

多くのユーザーは新規機能やパッケージを求めて Debian システムのテスト版testing(もしくは、非安定版 unstable) リリースを追いかけることを好みます。こういうことをするとクリティカルなパッケージのバグにシステムが遭遇しやすくなります。

apt-listbugs パッケージをインストールすれば、APT システムを使ってアップグレードする時に Debian の BTS を自動的にクリティカルなバグに関して点検することで、クリティカルなバグからあなたのシステムを防御できます。

apt-listchanges パッケージをインストールすれば、APT システムを使ってアップグレードする時に NEWS.Debian 中の重要ニュースを表示します。

各ディストリビューションのメタデーターのファイルは例えば "http://deb.debian.org/debian/" のような各 Debian ミラーサイトの "dist/コード名" の下に保存されています。そのアーカイブ構造はウェッブブラウザーで閲覧できます。6つのタイプの重要メタデーターがあります。

最近のアーカイブではネットワークトラフィックを減らすべく圧縮された差分ファイルとしてこれらのメタデーターは保存されています。

	ヒント
	セキュアー APT システムではトップレベルの "Release" ファイルがアーカイブを署名するのに使われています。

Debian アーカイブの各スイーツには例えば次に示すような "http://deb.debian.org/debian/dists/unstable/Release" のようなトップレベルの "Release" ファイルがあります。

Origin: Debian
Label: Debian
Suite: unstable
Codename: sid
Date: Sat, 14 May 2011 08:20:50 UTC
Valid-Until: Sat, 21 May 2011 08:20:50 UTC
Architectures: alpha amd64 armel hppa hurd-i386 i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390 sparc
Components: main contrib non-free
Description: Debian x.y Unstable - Not Released
MD5Sum:
 bdc8fa4b3f5e4a715dd0d56d176fc789 18876880 Contents-alpha.gz
 9469a03c94b85e010d116aeeab9614c0 19441880 Contents-amd64.gz
 3d68e206d7faa3aded660dc0996054fe 19203165 Contents-armel.gz
...

	注記
	「Debian アーカイブの基本」の中で "スイーツ (suite)" や "コード名 (codename)" を使う理由はこれを見れば分かるでしょう。"ディストリビューション" は "スイーツ" と "コード名" との両方を指したい際に用いられます。アーカイブが提供する全アーカイブ "エリア (area)" 名が "Components" の下にリストされます。

	ヒント
	アーカイブレベルの "Release" ファイルが apt_preferences(5) のルールに使われます。

"http://deb.debian.org/debian/dists/unstable/main/binary-amd64/Release" や "http://deb.debian.org/debian/dists/sid/main/binary-amd64/Release" 等の ソースリストが指定する全てのアーカイブロケーションにはアーカイブレベルの次に示すような "Release" ファイルがあります。

Archive: unstable
Origin: Debian
Label: Debian
Component: main
Architecture: amd64

	注意
	"Archive:" スタンザには、Debian アーカイブではスイート名 ("stable" や "testing" や "unstable" 等) が使われますが、Ubuntu アーカイブではコード名 ("trusty" や "xenial" や "artful" 等) が使われます。

experimental や bookworm-backports のような自動的にインストールされるべきでないパッケージを含むような一部アーカイブでは次に示す "http://deb.debian.org/debian/dists/experimental/main/binary-amd64/Release" のような追加の行があります。

Archive: experimental
Origin: Debian
Label: Debian
NotAutomatic: yes
Component: main
Architecture: amd64

lenny 以降の APT ツールではリモートから取得したメタデーターに追加でローカルで生成されるインストール状態情報を "/var/lib/apt/extended_states" に保存して、自動インストールされた全パッケージを全ての APT ツールで追跡するのに用います。

aptitude コマンドではリモートから取得したメタデーターに追加でローカルで生成されるインストール状態情報を "/var/lib/aptitude/pkgstates" に保存して用いています。

APT メカニズムでリモートから取得されたパッケージは消去されるまでは "/var/cache/apt/archives" に貯蔵されます。

aptitude では、このキャッシュファイルのクリーニングポリシーは "Options" → "Preferences" の下で設定でき、 "Actions" の下の "Clean package cache" か "Clean obsolete files" メニューによって強制実行できる。

Debian のパッケージファイルには特定の名前の構造があります。

dpkg(1) は Debian パッケージ管理の最も低レベルのツールです。非常に強力ですから気をつけて使う必要があります。

"パッケージ名"というパッケージをインストールする際に、dpkg は次に記す順番でパッケージを処理します。

"status" ファイルは dpkg(1) や "dselect update" や "apt-get -u dselect-upgrade" のようなツールによって使われます。

grep-dctrl(1) という専用の検索コマンドを使うと "status" と "available" メタデーターのローカルコピーを検索できます。

	ヒント
	デビアンインストーラー 環境下では、udpkg コマンドが udeb パッケージを開けるのに用いられます。udpkg コマンドはストリップダウンされたバージョンの dpkg コマンドです。

Debian システムには update-alternatives(8) を用いて何らかの重畳するプログラムを平和裏にインストールするメカニズムがあります。例えば vim と nvi の両方のパッケージがインストールされた状況下で vi コマンドが vim を選択して実行するようにできます。

$ ls -l $(type -p vi)
lrwxrwxrwx 1 root root 20 2007-03-24 19:05 /usr/bin/vi -> /etc/alternatives/vi
$ sudo update-alternatives --display vi
...
$ sudo update-alternatives --config vi
  Selection    Command
 ----------------------------------------------
      1        /usr/bin/vim
*+    2        /usr/bin/nvi

Enter to keep the default[*], or type selection number: 1

Debian の代替 (alternatives) システムは、その選択を "/etc/alternatives/" の中のシムリンクとして保持します。選択プロセスには "/var/lib/dpkg/alternatives/" の中の対応するファイルが使われます。

dpkg-statoverride(8) コマンドで提供される状態の上書きは、パッケージをインストールする際にファイルに関して異なる所有者やモードを使うよう dpkg(1) に指示する方法です。もし "--update" が指定されファイルが存在すれば、即座に新たな所有者やモードに設定されます。

	注意
	パッケージが所有するファイルの所有者やモードをシステム管理者が chmod や chown コマンドを用いて直接変更しても次回パッケージアップグレードによりリセットされます。

	注記
	ここでファイルと言いましたが、実際には dpkg が扱うディレクトリーやデバイス等のいかなるファイルシステムオブジェクトであってもいいです。

dpkg-divert(8) コマンドによって提供されるファイル迂回は、ファイルをデフォールトの場所ではなく迂回した場所にインストールするように dpkg(1) にさせます。dpkg-divert は本来パッケージメインテナンススクリプトのためのものです。システム管理者がこれを軽々に使うのはお薦めできません。

依存パッケージをインストールせず"sudo dpkg -i ..." でパッケージを強制インストールした場合、パッケージのインストールは部分インストールとなり失敗します。

APT システムか "sudo dpkg -i ..." を使って全ての依存パッケージをすべきです。

そして、全ての部分的にインストールされたパッケージを以下のコマンドで設定します。

# dpkg --configure -a

もしデスクトップ GUI プログラムが上流の大きなバージョンアップグレードの後に不安定性を経験した際には、そのプログラムが作った古いローカル設定ファイルとの干渉を疑うべきです。もし新規作成したユーザーアカウントでそのプログラムが安定なら、この仮説が裏付けられます。(これはパッケージングのバグで、通常パッケージャーによって回避されます。)

安定性を復元するには、対応するローカル設定ファイルを移動し GUI プログラムを再スタートします。後日設定情報を復元するために古い設定ファイルの内容を読む必要があるかもしれません。(あまり慌てて消去しないようにしましょう。)

パッケージスクリプト内のコマンドが何らかの理由でエラーを返しスクリプトがエラーで終了した場合には、パッケージ管理システムは動作を途中終了するので部分的にインストールされたパッケージのある状況が生まれます。パッケージがその削除スクリプト内にバグを持つ場合には、パッケージが削除不能になりうるので大変厄介です。

"パッケージ名" のパッケージスクリプトの問題に関しては、以下のパッケージスクリプトの内容を確認するべきです。

スクリプトの問題原因部分を以下のようなテクニックを使い root から編集します。

dpkg は非常に低レベルのパッケージツールなのでネットワーク接続もないブート不能な非常に劣悪な状況下でも機能します。foo パッケージが壊れていて置き換える必要があると仮定します。

もし何らかの理由で "/var/lib/dpkg/status" の内容が腐った場合には、Debian システムはパッケージ選択データーが失われ大きな打撃を被ります。古い "/var/lib/dpkg/status" ファイルは、"/var/lib/dpkg/status-old" や "/var/backups/dpkg.status.*" としてあるので探します。

"/var/backups/" は多くの重要な情報を保持しているので、これを別のパーティション上に置くのも良い考えです。

ひどく壊れた場合には、システムのバックアップをした後フレッシュに再インストールすることをお薦めします。たとえ "/var/" ディレクトリーの中が完全に消去されても、"/usr/share/doc/" ディレクトリー中から新規インストールのガイドとなる情報を復元できます。

最低限の (デスクトップ) システムを再インストールします。

# mkdir -p /path/to/old/system

"/path/to/old/system/" に古いシステムをマウントします。

# cd /path/to/old/system/usr/share/doc
# ls -1 >~/ls1.txt
# cd /usr/share/doc
# ls -1 >>~/ls1.txt
# cd
# sort ls1.txt | uniq | less

こうすると、インストールすべきパッケージ名が表示されます。("texmf" のようなパッケージ名以外が一部あるかもしれません。)

"/var/lib/dpkg/available" や "/usr/share/doc/package_name/changelog" の中にリストされたメンテナの名前は "誰がパッケージ化活動の背後にいるのか" に関していくばくかの情報を提供しますが、パッケージを実際にアップロードをした人がはっきりしません。devscripts パッケージ中の who-uploads(1) は Debian のソースパッケージを実際にアップロードした人を確定します。

APT によるダウンロードのバンド幅を例えば 800Kib/sec (=100kiB/sec) に制限したい場合には、APT のパラメーターを以下のように設定します。

APT::Acquire::http::Dl-Limit "800";

apt パッケージには、パッケージの自動ダウンロードのサポートする専用の cron スクリプト "/etc/cron.daily/apt" が同梱されています。このスクリプトは unattended-upgrades パッケージをインストールすることで自動アップグレード実行の機能拡張をします。これらは、"/usr/share/doc/unattended-upgrades/README" に記述されているように、"/etc/apt/apt.conf.d/02backup" と "/etc/apt/apt.conf.d/50unattended-upgrades" の中のパラメーターでカスタム化できます。

unattended-upgrades パッケージは基本的に stable システムのセキュリティーアップグレードのためです。既存の stable システムが、自動アップグレードで壊される危険性が、セキュリティーアップグレードがすでに閉じたセキュリティーホールからの侵入者によりシステムが壊わされる危険性より小さいなら、パラメーターを以下のように設定して自動アップグレードをするのも一計です。

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::Unattended-Upgrade "1";

テスト版 testing や非安定版 unstable システムを実行する場合には、自動アップグレードするとシステムはいつの日か確実に壊われるので、それはしたくないでしょう。そんなテスト版 testing や非安定版 unstable の場合でも、次に記すような事前にパッケージをダウンロードするパラメーターを設定でインタラクティブなアップグレードをするための時間を節約したいでしょう。

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::Unattended-Upgrade "0";

	警告
	外部のパッケージはあなたのシステムのルート権限を獲得することを意識するべきです。信頼できる外部のパッケージアーカイブのみを使うべきです。代替策は「矛盾した要求への対処法」を参照下さい。

ソースリストに Debian コンパチブルな外部パッケージアーカイブを加え "/etc/apt/trusted.gpg.d/" ディレクトリーそのアーカイブキーファイルを置くことで、セキュアー APT で そのアーカイブが使えます。sources.list(5) と apt-secure(8) と apt-key(8) を参照下さい。

	注意
	安定版 (stable) と security updates と stable-updates のような公式にサポートされた特定の組み合わせ以外は、混合したアーカイブソースからのパッケージをインストールすることを、公式には Debian ディストリビューションとしてサポートしていません。

testing を追跡しながら、unstable にある特定の新規アップストリームバージョンのパッケージを1回だけ取り入れる操作例を次に示します。

この様な手動のアプローチをすると "/etc/apt/preferences" ファイルを作ることもないし、また apt-pinning について悩むこともありません。でもこれではとても面倒です。

	注意
	混合したアーカイブソースを使うことを Debian が保証していないので、その場合にはパッケージ間の互換性は自分自身で確保しなければいけません。もしパッケージに互換性がないと、システムを壊すことになるかもしれません。この様な技術的要件を判断できる必要があります。ランダムな混合したアーカイブソースを使うことは全く任意の操作ですが、私としてはこの操作はお薦めできません。

異なるアーカイブからパッケージをインストールするための一般ルールは以下です。

	警告
	初心者のユーザーによる apt-pinning テクニックの利用は大トラブル発生を間違いなく起こします。絶対必要な時以外はこのテクニックの利用を避けなければいけません。

"/etc/apt/preferences" ファイル無しだと、APT システムはバージョン文字列を用いて、最新利用可能バージョンを候補バージョンとします。これが普通状態で APT システムの最も推薦される使い方です。全ての公式にサポートされたアーカイブの組み合わせは、自動的にアップグレードするソースとすべきでないアーカイブは NotAutomatic とマークされ適正な扱いを受けるので、"/etc/apt/preferences" ファイルを必要としません。

	ヒント
	バージョン文字列比較ルールは、例えば "dpkg --compare-versions ver1.1 gt ver1.1~1; echo $?" とすれば確認できます (dpkg(1) 参照下さい)。

ターゲットのリリースアーカイブは"apt-get install -t testing some-package" のようにコマンドラインオプションによって設定できます。

	警告
	初心者のユーザーによる apt-pinning テクニックの利用は大トラブル発生を間違いなく起こします。絶対必要な時以外はこのテクニックの利用を避けなければいけません。

たとえ "推奨 (Recommends)" されていても自動的に特定のパッケージが引きこまれ無くしたいときには、"/etc/apt/preferences" ファイルを作成しその中に全てのパッケージを以下のように明示的にリストしなければいけません。

Package: package-1
Pin: version *
Pin-Priority: -1

Package: package-2
Pin: version *
Pin-Priority: -1

	警告
	初心者のユーザーによる apt-pinning テクニックの利用は大トラブル発生を間違いなく起こします。絶対必要な時以外はこのテクニックの利用を避けなければいけません。

testing を追跡しながら、unstable にある特定の新規アップストリームバージョンのパッケージが定常的にアップグレードされる、apt-pinning テクニックの例を次に示します。全ての必要なアーカイブを "/etc/apt/sources.list" ファイル中に以下のようにリストします。

deb http://deb.debian.org/debian/ testing main contrib non-free
deb http://deb.debian.org/debian/ unstable main contrib non-free
deb http://security.debian.org/debian-security testing-security main contrib

"/etc/apt/preferences" を以下のように設定します。

Package: *
Pin: release a=unstable
Pin-Priority: 100

"package-name" という名前のパッケージとその依存ファイルを unstable アーカイブからこの設定の下でインストールしたい場合、"-t" オプションを使ってターゲットのリリースを切り替える (unstable の Pin-Priority が990 になる) 以下のコマンドを実行します。

$ sudo apt-get install -t unstable package-name

この設定では、通常の "apt-get upgrade" や "apt-get dist-upgrade" ("aptitude safe-upgrade" や "aptitude full-upgrade") の実行は、testing アーカイブからインストールされたパッケージは最新の testing アーカイブを使ってアップグレードし、unstable アーカイブからインストールされたパッケージは最新の unstable アーカイブを使ってアップグレードします。

	注意
	"/etc/apt/sources.list" ファイルから "testing" の項目を削除しないように注意します。"testing" 項目がその中にないと、APT システムは最新の unstable アーカイブを使ってアップグレードします。

	ヒント
	著者は上記操作のすぐ後に "/etc/apt/sources.list" ファイルを通常編集して "unstable" アーカイブ項目をコメントアウトします。こうすることで、最新の unstable アーカイブによって unstable からインストールされたパッケージをアップグレードしなくなりますが、"/etc/apt/sources.list" ファイル中に項目が多すぎて更新のプロセスが遅くなることを避けられます。

	ヒント
	もし "/etc/apt/preferences" ファイル中で "Pin-Priority: 100" の代わりに "Pin-Priority: 1" が用いられた場合は、"/etc/apt/sources.list" ファイルの中の "testing" 項目が削除されようと、Pin-Priority 値は100 のインストール済みパッケージは unstable アーカイブによってアップグレードされる事はありません。

最初の "-t unstable" によるインストール無しに、unstable の特定パッケージを自動的に追跡したい場合、"/etc/apt/preferences" ファイルを作りそのトップにこれらパッケージを明示的に以下のようにリストします。

Package: package-1
Pin: release a=unstable
Pin-Priority: 700

Package: package-2
Pin: release a=unstable
Pin-Priority: 700

以上で、各特定パッケージに関して Pin-Priority 値が設定されます。例えば最新の unstable バージョンのこの "Debian リファレンス" を英語版で追跡するためには、"/etc/apt/preferences" ファイルに以下の項目を設定します。

Package: debian-reference-en
Pin: release a=unstable
Pin-Priority: 700

Package: debian-reference-common
Pin: release a=unstable
Pin-Priority: 700

	ヒント
	この apt-pinning テクニックは stable アーカイブを追跡している際にも有効です。著者の経験では、文書パッケージは unstable アーカイブからインストールしても今までいつも安全でした。

	警告
	初心者のユーザーによる apt-pinning テクニックの利用は大トラブル発生を間違いなく起こします。絶対必要な時以外はこのテクニックの利用を避けなければいけません。

次に unstable を追跡しながら experimental にある特定の新規アップストリームバージョンのパッケージを取り込む apt-pinning テクニックの例を示します。すべての必要なアーカイブを "/etc/apt/sources.list" ファイルに以下のようにリストします。

deb http://deb.debian.org/debian/ unstable main contrib non-free
deb http://deb.debian.org/debian/ experimental main contrib non-free
deb http://security.debian.org/ testing-security main contrib

ソースからプログラムをコンパイルして Debian パッケージを置換えたい際には、それを実際にローカルで Debian 化してパッケージ (*.deb) して、私的アーカイブを使うのが好ましいです。

しかし、プログラムをソースからコンパイルして "/usr/local" にインストールすることを選んだ際には、パッケージ依存関係を満足させるための最後の手段として equivs を使う必要があるかもしれません。

Package: equivs
Priority: optional
Section: admin
Description: Circumventing Debian package dependencies
 This package provides a tool to create trivial Debian packages.
 Typically these packages contain only dependency information, but they
 can also include normal installed files like other packages do.
 .
 One use for this is to create a metapackage: a package whose sole
 purpose is to declare dependencies and conflicts on other packages so
 that these will be automatically installed, upgraded, or removed.
 .
 Another use is to circumvent dependency checking: by letting dpkg
 think a particular package name and version is installed when it
 isn't, you can work around bugs in other packages' dependencies.
 (Please do still file such bugs, though.)

	注意
	ここに書かれた手順がシステムの違いのために追加の手動の努力無しにうまく行く保証はありません。

stable システムの部分アップグレードのためには、その環境内でソースパッケージを使ってパッケージをリビルドするのが好ましいです。こうすることでパッケージ依存関係による大掛かりなアップグレードをしないで済みます。

stable システムのための "/etc/apt/sources.list" ファイルに以下のエントリーを追加します。

deb-src http://deb.debian.org/debian unstable  main contrib non-free

コンパイルするのに必要なパッケージをインストールしソースパッケージをダウンロードをします。

# apt-get update
# apt-get dist-upgrade
# apt-get install fakeroot devscripts build-essential
# apt-get build-dep foo
$ apt-get source foo
$ cd foo*

バックポートに必要な際には、dpkg や debhelper 等のツールチェインパッケージをバックポートパッケージを用いて更新します。

次を実行します。

$ dch -i

"+bp1" を後ろに付けるなどして、"debian/changelog" 中でパッケージバージョンを先に進める

以下のようにしてパッケージをビルドしシステムにインストールします。

$ debuild
$ cd ..
# debi foo*.changes

パッケージ管理に関しては以下の文書からさらに学習できます。