パッケージやパッケージシステムの FAQ



パッケージシステムの FAQ

パッケージ管理には apt と aptitude のどちらを使えばいいのですか?

etch や lenny では aptitude を使うことが推奨されていました。

squeeze 以降では、インタラクティブなツールとしては aptitude、 ノンインタラクティブなコマンドラインツールとしては apt-get が推奨されています。 特に、 lenny → squeeze や squeeze → wheezy のアップグレードの際は、 apt-get を使うことが推奨されています。

apt と aptitude の利用について

lenny 以降の apt は aptitude の拡張管理情報を扱えるので、混在して利用しても問題ありません。

aptitude の拡張情報を apt で共有するためには、一度 aptitude を実行しておく必要があります。

参照:

aptitude の特徴

  • Aptitude は APT のフロントエンドである。
  • システムにインストールされたパッケージの情報を扱うことができる。
  • Ncurses ベースのメニューシステムにより直感的に操作できる。
  • apt-get を置き換えるコマンドラインインターフェイスを持っている。
  • コマンド1発で設定やデータベースをバックアップ/リストアできる。
  • この aptitude にはスーパー牛さんパワーなどはありません。;)

参照:

aptitude の使い方を知りたい

メニューシステムとして使う

コマンドラインから

$ aptitude

root 権限が必要になる場面では root パスワードの入力を求められます。

基本的な操作はカーソルキーを使って移動。Enter キーを使って選択。q キーで終了です。 パッケージ操作は最後に g キーを押して実行しない限り変更されません。
最初から操作をやり直したい場合は、Ctrl+u (Ctrl キーと u キーを一緒に押す)で操作を取り消すことができます。

キーバインド一覧
カーソルキー上下カーソル移動
Page Up/Page Down
Enter選択
Ctrl+T/F10メニュー選択
?ヘルプ表示
q終了
uパッケージ一覧をアップデートする
+パッケージをインストール(install)マークをつける
-パッケージを削除(delete)マークをつける
_パッケージを完全に削除(purge)のマークをつける
=パッケージを固定(hold)のマークをつける
:マークを外す
Lパッケージを再インストールする
F特定バージョンへの自動更新を禁止する
gつけたマークを実行する
Ctrl+uアクションをすべて取り消す
/パッケージの前方検索
\パッケージの後方検索
[パッケージグループを開く
]パッケージグループをたたむ

メニューシステムを使っている時の Tips

「更新可能なパッケージ」などのパッケージグループの上でも、+ キーや−キーなどを使ってパッケージ操作をすることができます。 sid を使っているとパッケージの更新が大量にある時がありますが、その場合「更新可能なパッケージ」の上で+キーを押すと、 一度にパッケージをアップデートすることができて便利です。

コマンドラインから使う

apt の使い方とほぼ同じです。

使用方法: aptitude [オプション]<アクション> ...

例えばパッケージをインストールするなら

aptitude install (パッケージ名)

のように使います。

アクション一覧(aptitude 0.4.10)
installパッケージをインストール・更新します
removeパッケージを削除します
purgeパッケージと設定ファイルを削除します
holdパッケージを固定します
unholdパッケージの固定を解除します
markauto自動的にインストールされたマークをパッケージにつけます
unmarkauto手動でインストールされたマークをパッケージにつけます
forbid-versionaptitude に特定のパッケージバージョンの更新を禁止させます
update新規および更新可能なパッケージの一覧をダウンロードします
safe-upgrade (lenny以降)安全なアップグレード。以前「upgrade」と知られていたアクション
upgrade (etch以前)
full-upgrade (lenny以降)状況によりパッケージをアンインストールしたり追加するアップグレード。以前「dist-upgrade」と知られていたアクション
dist-upgrade (etch以前)
forget-newどのパッケージが「新規」かの情報を消去します
search名前や正規表現でパッケージを検索します
showパッケージについての詳細な情報を表示します
cleanダウンロード済みのパッケージファイルを消去します
autoclean古いダウンロード済みのパッケージファイルを消去します
changelogパッケージの変更履歴を表示します
downloadパッケージ用の .deb ファイルをダウンロードします
reinstall現在インストールされているパッケージをダウンロードし (場合によっては) 再インストールします

参照:

apt の使い方を知りたい

apt/aptitude 使用時に "GPG error" が出る

参照:

etch 以降ではパッケージの改竄を防止するため secure apt (apt-secure) というシステムが 導入されています。
これは apt-key というコマンド (実態は gpg コマンドのラッパースクリプト) と Release.gpg というパッケージリポジトリにあるファイルによって構成されています。

主なエラー

1. /etc/apt/trusted.gpg がない

W: GPG error: http://ftp.jp.debian.org unstable Release: Couldn't access keyring: No such file or directory

以下のコマンドを実行してください。

# apt-key update

上記コマンドを実行すると/etc/apt/trusted.gpg が自動生成されます。 なければ手動でコピーしてください。

# cp /usr/share/keyrings/debian-archive-keyring.gpg /etc/apt/trusted.gpg

2. 公式アーカイブの鍵が失効している

W: GPG error: http://ftp.jp.debian.org unstable Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY F1D53D8C4F368D5D

公式アーカイブのための公開鍵はある程度経つと失効するため、 必要に応じて公開鍵を更新しなければなりません。

通常は、新しい鍵を同梱した apt パッケージに更新することでこの問題を回避することができます。 (新しい鍵が apt パッケージに反映されるのに少し時間がかかるかもしれません。)

メンテナスクリプトが鍵をコピーしてくれますが、正常に更新されない場合は、手動で鍵をコピーしてください。

# cp /usr/share/keyrings/debian-archive-keyring.gpg /etc/apt/trusted.gpg

また、鍵自体は debian-archive-keyring として独立したパッケージにもなっています。

他の鍵のありかとしては、 ftp-master の "Archive signing key" などがあります。
例えば、2007 年 (4.0/etch) のものは、https://ftp-master.debian.org/archive-key-4.0.asc です。 導入方法は、

# wget https://ftp-master.debian.org/archive-key-4.0.asc -O - | apt-key add -

以上の方法でも駄目な場合は、次の"パッケージリポジトリの鍵を導入する方法"を参照してください。

パッケージリポジトリの鍵を導入する方法

バイナリ形式の公開鍵が取得できるときは、/etc/apt/trusted.gpg.d/ 以下に放り込むだけで OK。

公式、非公式含め、各パッケージリポジトリ (apt-line) の鍵 ID が判明している時は、次の様に導入して下さい。

# gpg --keyserver (鍵サーバ名) --recv-keys (鍵 ID)
# gpg --armor --export (鍵 ID) | apt-key add -

例) 鍵サーバ名 = wwwkeys.eu.pgp.net、鍵 ID = 1F41B907 (Christian Marillat)

鍵 ID はエラーメッセージなどに表示されます。 (NO_PUBKEY 以下の 16 文字もしくは 0x... で始まる 16 進数表示の 8 文字のもの)

他の鍵サーバ: pgp.nic.ad.jp など

# gpg --keyserver wwwkeys.eu.pgp.net --recv-keys 1F41B907

必要ならば署名の検証をして下さい。

# gpg --check-sigs 1F41B907
# gpg --fingerprint 1F41B907

最後に鍵を apt-key を用いてインポートして下さい。

# gpg --armor --export 1F41B907 | apt-key add -

再度 aptitude update すれば GPG error が解消されます。

鍵の更新

# apt-key update

を実行してください。

その他

グラフィカルなツールとして、gui-apt-key などがあります。

apt ではなく dpkg を使ってもパッケージの管理 (インストールや削除) ができますか

できますが、パッケージの依存関係がしっかりと理解できないならば、やめておいた方が良いでしょう。

apt は基本的に dpkg が適切に処理できるように、パッケージの取得や依存関係の解決などを行ない、 整理したものを dpkg に渡す仕事をしています。 apt を使わない場合、これらをすべて自力で行なわなくてはならず面倒ではありますが管理自体は可能です。

これらの関係を Red Hat Enterprise Linux で置き替えるならば dpkg が rpm コマンド、apt/aptitude が yum コマンドに相当します。

dpkg によるインストールでは、依存関係に必要なすべてのファイルをあらかじめ手元に用意し、 依存関係に従って順番通りにインストールする必要があります。

dpkg の基本的なコマンドを知りたい

よく使うと思われる代表的なコマンドには、次のものがあります。

dpkgコマンド
新規/アップグレード・インストール時# dpkg -i パッケージファイル名
アンインストール (削除) 時# dpkg -r パッケージ名

その他のコマンド / オプション (他にも多数あるので関連項目を参照)

コマンド機能・簡単な説明
$ dpkg -lインストール済みパッケージの一覧を表示させる
$ dpkg -s パッケージ名パッケージの詳細情報を表示させる

インストール済のすべてのパッケージの一覧が見たい

$ dpkg -l

ページャなどに出力すると読み易いです

$ dpkg -l | pager

また、環境変数 COLUMNS でリストのコラム数を指定できます

$ COLUMNS=100 dpkg -l

インストール済のパッケージに含まれているファイルの一覧を見たい

$ dpkg -L (パッケージ名)

ページャなどに出力すると読み易いです

$ dpkg -L | pager

インストール済のコマンドやファイルがどのパッケージに入ってるか探したい

  • dpkg と which で探す
    $ dpkg -S `which (コマンド名)`

    例:

    $ dpkg -S `which ps`
    procps: /bin/ps
  • dlocate で探す
    # aptitude install dlocate
    # update-dlocatedb
    $ dlocate (コマンド名やファイル名)

インストールしてないコマンドやファイルがどのパッケージに入ってるか探したい

本家のサイトにある「パッケージの内容を検索」で探す

https://www.debian.org/distrib/packages#search_contents

別途 CUI ツールをインストールして使う

auto-aptapt-file などがある。

# aptitude install auto-apt
# auto-apt update
$ auto-apt search (ファイル名)
$ auto-apt search bin/(コマンド名)
$ auto-apt search (コマンド名) | grep -w (コマンドのフルパスの頭から"/"を取ったもの)
# aptitude install apt-file
# apt-file update
$ apt-file search (コマンドやファイル名)
$ apt-file search (コマンド名) | grep -w (コマンドのフルパスの頭から"/"を取ったもの)

別途 GUI ツールをインストールして使う

synapticpackagesearch などがある。

# aptitude install synaptic
$ synaptic
# aptitude install packagesearch
$ packagesearch

パッケージファイルの中身が見たい

$ dpkg -c (パッケージファイル名)

例:

$ dpkg -c w3m_0.5.1-3_i386.deb

パッケージファイルの中身を取り出したい

アプリやライブラリなどのファイルを取り出したい場合は

$ dpkg -x (パッケージファイル名) (展開するディレクトリ)

例:

$ dpkg -x w3m_0.5.1-3_i386.deb ~/w3m_data

postinst や postrm などのメンテナスクリプトを取り出したい場合は

$ dpkg -e (パッケージファイル名) (展開するディレクトリ)

例:

$ dpkg -e w3m_0.5.1-3_i386.deb ~/w3m_control

binutils に入っている ar を使うと、構成ファイルとメンテナスクリプトの両方が取り出せる。
control.tar.gz にはメンテナスクリプト、チェックサムなど、data.tar.gz には構成ファイルが入っている。

$ ar x (パッケージファイル名)
$ tar xf control.tar.gz
$ tar xf data.tar.gz

パッケージのバージョンを指定してインストールしたい

# aptitude install (パッケージ名)=(バージョン)

例:

# aptitude install apache=1.3.26-0woody3

もちろん apt-line やローカルのキャッシュに指定したファイルがないと駄目です。

testing や unstable のパッケージを借りたい

testing/unstable のパッケージを借りる前に、 stable 用に testing/unstable のパッケージをバックポートした Debian Backports を探してみましたか?

まずは Backports パッケージ検索のページ から検索したり、 wheezy-backportsのセクション一覧 から探してみて、 なければ以下のことをしてみてもよいでしょう。

ただし、安易に testing や unstable の apt-line を追加してパッケージをインストールしようとすると、 libc6 などの根幹にかかわるパッケージも依存関係でアップグレードされ、 大変なことになる可能性もあるので慎重に作業をしてください。

ターゲットリリースの指定

/etc/apt.conf 或いは /etc/apt/apt.conf.d/ 配下にファイルを作成してデフォルトのターゲットリリースを指定する。

例えば /etc/apt/apt.conf.d/99target に

APT::Default-Release "stable";

と書く。 *1 その後、 testing や unstable 等の apt-line を追加する。

# aptitude install (パッケージ名)

で stable のパッケージが入る。

testing や unstable から一時的にパッケージを借りる場合はそれぞれ以下のようにする。

# aptitude install (パッケージ名)/testing
# aptitude install (パッケージ名)/unstable

或いは

# aptitude -t testing install (パッケージ名)
# aptitude -t unstable install (パッケージ名)

この場合、このパッケージが testing や unstable でバージョンアップされても上記インストール時のパッケージがキープされる。

preferences を使う

上記の ターゲットリリースを指定 する代わりに、 /etc/apt/preferences でパッケージのプライオリティを指定する。
(/etc/apt/preferences.d ディレクトリがある場合は同様の内容のファイルをそこに置いてもよい。)

例えば、

Package: *
Pin: release a=testing
Pin-Priority: 110

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

のように書く。 (100 < testing < 500, 1 < unstable < 100) リリース間は空行で分離する。
こちらを用いることの利点は、

  1. 非公式なパッケージもバージョンナンバーが大きければちゃんとインストールされる。
  2. pin を使って入れた testing または unstable パッケージはそれ以降 testing の最新版が入るようになる。
  3. もちろん、特にいじらないパッケージは stable のまま。

squeeze まではリリースの指定に stable / testing / unstable のようなアーカイブ名しか指定できなかったが、 wheezy 以降は以下のように wheezy / jessie / sid のようなコード名の指定も可能となった。

Package: *
Pin: release n=jessie
Pin-Priority: 110

Pin-Priority の値の意味は以下の表を参考に

Pin-Priority意味
0未満(マイナス値)インストールしない
(1)NotAutomatic アーカイブ (experimental等) の priority
1-99指定すればインストールできるが、アップグレードの対象にはならない
(100)現在インストールされているパッケージの priority
NotAutomatic + ButAutomaticUpgrades アーカイブ (backports等) の priority
100-499通常のアーカイブよりも優先度が低いが、指定してインストールしたものはアップグレードの対象になる
(500)「ターゲットリリース」に指定されていない通常のアーカイブの priority
500-989「ターゲットリリース」指定のアーカイブよりも優先度が低いが、アップグレードの対象になる
(990)「ターゲットリリース」に指定したアーカイブの priority
990-999現在インストールされているパッケージよりも新しければ「ターゲットリリース」指定に関係なくインストールされる
1000以上ダウングレードしてでもそのパッケージをインストールさせる

デフォルトの状態 (/etc/apt/preferences が書かれていない状態) では apt-line に指定したアーカイブは (NotAutomatic アーカイブを除き) priority = 500 であり、

Package: *
Pin: release a=experimental
Pin-Priority: 1

Package: *
Pin: release l=Debian Backports
Pin-Priority: 100

Package: *
Pin: (特に指定しないデフォルト)
Pin-Priority: 500

と指定した場合とほぼ同じ状態になっている。

/etc/apt/apt.conf.d/99target で

APT::Default-Release "stable";

のようにデフォルトターゲットを指定すると /etc/apt/preferences で

Package: *
Pin: release a=stable
Pin-Priority: 990

と指定した場合と同じ意味合いを持つ。

# aptitude -t unstable install (パッケージ名)

のように指定してインストールした場合は、一時的に (aptitude コマンドの実行中は)

Package: (パッケージ名)
Pin: release a=unstable
Pin-Priority: 990

と指定した場合と同じ効力を持つ。

インストール済みのパッケージ・バージョンは priority = 100 であり、 priority 100 より高いアーカイブの中にインストール済みのパッケージのバージョンよりも高いバージョンがあれば、 その中で一番高い priority のアーカイブのバージョンにアップグレードされる。 例えば、

installed:    version 1.0-1
priority 90:  version 2.0-1
priority 500: version 1.5-3
priority 990: version 1.0-3

の場合には、priority 990 の version 1.0-3 にアップグレードされる。

installed:    version 1.5-1
priority 90:  version 2.0-1
priority 500: version 1.5-3
priority 990: version 1.0-3

の場合には、priority 500 の version 1.5-3 にアップグレードされる。 実際の例は apt-cache policy コマンド の実行結果参照。

このやりかたは、apt-pinning と呼ばれているようです。

参考:

メジャーリリース直後の apt-pinning お勧め設定

apt-pinning を利用している環境で、メジャーリリース直後、 メジャーリリースの適用を一時保留したいような場合の設定方法。

例えば、etch がリリースされた状況で、一時的に etch へのアップデートを保留して、 sarge の更新を取得/適用することができる。

上記の preferences を使う の設定に加えて、 新規のリリースをバージョン (リビジョン) 指定で Pin しておく。例えば、 sarge -> etch を保留するのであれば、

Package: *
Pin: release l=Debian-Security, a=stable
Pin-Priority: 97

Package: *
Pin: release v=4.0
Pin-Priority: 95

Package: *
Pin: release v=4.0r0
Pin-Priority: 95

Package: *
Pin: release v=4.0r1
Pin-Priority: 95

を追加しておく。これで、etch のパッケージが stable になっても、 無条件で導入されてしまうことはない。

もちろん、sarge をインストールしつづけるために、例えば下記のような、 stable ではなく sarge を指定した apt-line を追加しておく必要がある。

deb http://pkg_src/pub/linux/debian/debian sarge main contrib non-free

また、Pin はマイナーリリース毎に設定する必要があるので、 この状態で長期運用する予定があるならば、v=4.0r5 くらいまで項目を追加しておくと良い。

Pin の状態やターゲットは、 apt-cache policy コマンド で確認できる。

リビルドする

パッケージに自分で修正を加えたいを読んでください。 修正を加えず単にビルドするだけです。

特定のパッケージをアップグレードの対象から外したい

最も単純な方法

# aptitude hold (パッケージ名)

例:

# aptitude hold jnethack
# echo (パッケージ名) hold | dpkg --set-selections

例:

# echo jnethack hold | dpkg --set-selections

/etc/apt/preferences に留めておきたいパッケージ名とバージョンを書く方法

Package: (パッケージ名)
Pin: version (バージョン)
Pin-Priority: (優先度)

例:

Package: jnethack
Pin: version 1.1.5-11
Pin-Priority: 1001

testing/unstable から stable にダウングレードしたい

不可能ではありませんが、現在では推奨されません。

Debianリファレンス - 2.7.7. 緊急ダウングレード 参照

どのパッケージを testing や unstable から借りてるか知りたい

apt-show-versions を使うとよいでしょう。 例えば testing を使っているけど一部 unstable から借りている場合

$ apt-show-versions | grep unstable

パッケージのバージョンを調べたい

apt-show-versions を使うと便利です。 たとえば stable 環境で apache のバージョンを知りたければ

$ apt-show-versions -p apache
apache/stable uptodate 1.3.26-0woody3

といった感じに出力されます。 testing/unstable のバージョンも知りたければ、

$ apt-show-versions -a -p apache
apache  1.3.26-0woody3  install ok installed
apache  1.3.26-0woody3  stable
No proposed-updates version
apache  1.3.26-1.1      testing
apache  1.3.27-0.1      unstable
apache/stable uptodate 1.3.26-0woody3

のように出力されます。

あるパッケージがどの apt-line からインストールされるのか知りたい

$ apt-cache policy パッケージ名

あるパッケージがどのパッケージに依存している/されているのか知りたい

どのパッケージに依存しているのか調べるには

$ apt-cache depends (パッケージ名)

apt-rdepends を使えば指定したパッケージに依存しているパッケージの依存状態も表示できる。

$ apt-rdepends (パッケージ名)

どのパッケージに依存されているのか調べるには

$ apt-cache rdepends (パッケージ名)

依存関係から孤立したパッケージを探すには

deborphan を使いましょう。

$ deborphan --guess-all

削除する場合に便利なフロントエンドもあります。

# orphaner --guess-all

また GTK+ フロントエンドの gtkorphan もあります。

依存関係から孤立したパッケージを探索から外すには

他のパッケージから依存されていなくても、自分のプログラムに必要などでインストールしたパッケージが deborphan に引っかかる場合、

# deborphan --add-keep (パッケージ名)

で除外することができます。

依存関係で足りないパッケージを探すには

# apt-get check

recommends なパッケージを自動的にインストールさせたくない

aptitude は depends に加えて recommends なパッケージもインストールするようになっています。 recommends をインストール対象から外すには

# aptitude -R install (パッケージ名)

この振舞いをデフォルトにするには aptitude をフルスクリーンモードで起動して

# aptitude

F10 → Options → Dependency handling → Install Recommended packages automatically のチェックを外しておきます。

もしくは /etc/apt/apt.confに

APT::Install-Recommends "false";

と書いておきます。

aptitude upgrade で消したくないパッケージを REMOVE すると言ってきます。

aptitude は指定してインストールしたものか、自動的にインストールされたものかを記録しています。 自動的にインストールされたものとして記録されているパッケージが、依存関係で孤立すると、それはシステムに不要なものであると判断します。

「指定してインストールしたもの」に変更するには

# aptitude unmarkauto (パッケージ名)

「自動的にインストールされたもの」に変更するには

# aptitude markauto (パッケージ名)

既存のシステムと全く同じパッケージ構成にしたい

既存のシステムと全く同じパッケージ構成を再現したいときには、 既存のマシンから、

$ dpkg --get-selections > list

でパッケージ構成を取得、/var/lib/apt/extended_states と共に新規マシンにコピーし、

# dpkg --set-selections < list
# apt-get dselect-upgrade

とすれば、パッケージリストファイルの内容にしたがってパッケージがインストールされます。

aptitude の構成情報を全てアーカイブするには、

# aptitude-create-state-bundle archive.tar.bz2

(上記アーカイブには dpkg, apt の構成情報も含まれています。)
上記 archive.tar.bz2 を新しいシステム上で反映させるには、

# aptitude-run-state-bundle archive.tar.bz2

初回インストール時の質問による設定をもう一度したい

# dpkg-reconfigure (パッケージ名)

例:

# dpkg-reconfigure debconf

このパッケージ設定フレームワークは debconf と呼ばれます。

参照:

パッケージインストール時の質問がウザい

Debconf の質問に関する設定を変更しましょう。

# dpkg-reconfigure debconf

例えば「低 (low)」にすると用意されている質問をすべて表示します。
「高 (high)」にするとデフォルト選択肢が用意されていない質問のみ表示します。

Debconf を使用するパッケージを探したい

configure-debian をインストールして、

# configure-debian

を実行すると、admin や base などの各サブセクション毎に Debconf を使用する パッケージがリストアップされ、パッケージを選択することにより、Debconf を用いて 再設定できます。

dpkg -l でパッケージ名とかバージョンが途中までしか表示されない

環境変数 COLUMNS を大きな値 (200 とか) に設定してみてください。
例:

$ COLUMNS=200 dpkg -l

alias に登録しておくという手もあります。

$ alias dpkg='COLUMNS=${COLUMNS:-80} dpkg' 

ローカルにあるパッケージを APT でインストールしたい

apt-ftparchive

  • .deb
  • .dsc
  • .diff.gz (or .debian.tar.gz)
  • .changes
  • .orig.tar.gz

を同じディレクトリに突っ込む。
(本当は公式アーカイブのようにアーキテクチャ、リリース毎にディレクトリを分けるべきだが、ここでは説明しない。)
以下このディレクトリで作業する。

以下の内容で apt-archive.conf を作成

Dir {
  ArchiveDir "." ;
};

BinDirectory "." {
  Packages "./Packages" ;
  Sources "./Sources" ;
  Contents "./Contents-i386" ;
};

apt-utils パッケージインストール後、以下のコマンドを実行

$ apt-ftparchive generate apt-archive.conf

これでカレントディレクトリに Packages, Packages.gz, Sources, Sources.gz, Contents-i386 Contents-i386.gz が生成される。

続いて以下の内容で、apt-release.conf ファイルを作成

APT {
  FTPArchive {
    Release {
      Origin "unreleased" ;
      Label "unreleased" ;
      Suite "unstable" ;
      Codename "sid" ;
      Architectures "i386 all source" ;
      Components "main contrib non-free" ;
      Description "Unofficial packages - Not Released" ;
     };
  };
};

以下のコマンドを実行

$ LANG=C apt-ftparchive -c apt-release.conf release . > Release

署名済 Release ファイルを生成

$ gpg -abs -o Release.gpg Release

この時署名に使用した公開鍵を /etc/apt/trusted.gpg.d/ ディレクトリにバイナリ形式で放り込む。

# gpg --export (GPG 公開鍵の ID) > /etc/apt/trusted.gpg.d/local.gpg
# apt-key list
...
/etc/apt/trusted.gpg.d//local.gpg
---------------------------------
...

最後に sources.list に ローカルパッケージをインストールするための apt-line を追加する。
通常は file プロトコルを使用すればよいが、.deb ファイルが /var/cache/apt/archives 以下にコピーされるようにするには、 copy プロトコルを使用する。

deb file:(ディレクトリ) ./
deb-src file:(ディレクトリ) ./

または、

deb copy:(ディレクトリ) ./
deb-src copy:(ディレクトリ) ./

例:

deb file:/usr/src/ ./

apt-line を追加したら、

# aptitude update && aptitude install (パッケージ名)

で完了。

参考:

  • man apt-ftparchive(1)
  • /usr/share/doc/apt/offline.html

gdebi

GUIだったら、gnomeのファイルマネージャの右クリックに、「Gdebi パッケージ マネージャで開く」がある。

gnomeを載せてないサーバなどの環境では、gdebi-coreをインストール:

$ sudo aptitude install gdebi-core
$ sudo gdebi パッケージ名.deb

で、aptを呼び出して、関連のパッケージも入れてくれる。

/etc/apt/sources.list を分割したい

apt の バージョン 0.6.43 以降では、/etc/apt/sources.list と同じ書式の、"."で始まらず、 英数字と "_" "-" "." だけからなり、拡張子が "list" のファイルをディレクトリ /etc/apt/sources.list.d に配置すると、読み込んでくれます。
これにより肥大化した sources.list を分割することができます。

自動で upgrade させたいんですけど

unattended-upgrades を使いましょう。

aptitude upgrade したときのパッケージの変更点を知りたい

aptitudeでは知りたいパッケージにカーソルを合わせ「C(大文字)」キーを押すと、ChangeLogが表示されるので変更点を知ることができます。

他には apt-listchanges を使う方法もあります。
apt-listchangesをインストールしているとアップグレードされるパッケージの変更点を表示してくれます。

ChangeLog の表示方法など、各種設定を行うには次を実行してください。

# dpkg-reconfigure apt-listchanges

apt-get -u upgrade も使える?

aptitude install/upgrade 時にパッケージの BTS を調査したい

apt-listbugs をインストールしましょう。

パッケージのセキュリティの状態を調査したい

debsecan というパッケージがあります。 これは現在インストールされているパッケージのセキュリティホールを cron を用いてリストアップしてくれます。

主なエラー

aptitude や apt にて dpkg がエラーを吐く

原因:
/var/lib/dpkg/status が壊れた事で debconf の install 状態が 不明になったため
対処:
/var/lib/dpkg/status を別の場所から取ってくる
  1. /var/lib/dpkg/status-old
  2. /var/backups/dpkg.status.*
  3. 他のマシンから持ってくる

参考:
http://lists.debian.or.jp/debian-users/200404/msg00132.html

/var/cache/apt/available が頻繁に壊れるんだけど

まずは memtest86 等でメモリチェックしてみましょう。 grub などのブートローダから起動する事もできます。

参考:
http://lists.debian.or.jp/debian-users/200408/msg00098.html

まさかディスクが不良ブロックだらけって事はないよね?

# badblocks -v /dev/hda1

ext2/ext3/ext4 なら該当パーテョションをマウントしていない状態で

# e2fsck -cf /dev/hda1

すればファイルシステムが不良ブロックを使う事を回避できる。

XFS, JFS な人は不良ブロックを回避できないらしい?

apt-get でセグメンテーション違反が出た

# mv /var/cache/apt/pkgcache.bin /var/cache/apt/pkgcache.bin.bak
# mv /var/cache/apt/srcpkgcache.bin /var/cache/apt/srcpkgcache.bin.bak

してから、apt-get update してみると回避できるかもしれません。
上記で駄目なら以下も試してみてください。

dpkg --configure -a 

「壊れているか、完全にインストールされていません」というエラーが出る

パッケージの状態がおかしくなっているのかもしれません。

# apt-get install -f

# dpkg --configure -a

でほとんどの場合はシステムを修復できます。 失敗した場合「どのパッケージが原因となって失敗したか」というメッセー ジが出力されるので、それを元に手作業で修復しましょう。

  • そのパッケージを再インストールしてみる
  • そのパッケージを削除して再インストールしてみる
  • そのパッケージのメンテナスクリプトを調べてみる

参考:
http://lists.debian.or.jp/debian-users/200409/msg00086.html

apt の "-f" オプションでも問題が解決しないとき

下記のようなエラーメッセージが返ってくることがあります。

−−−−−−−−−−省略−−−−−−−−−−
dpkg: /var/cache/apt/archives/package-AAA*.deb の読み込みエラーです(--unpack):
`*'を上書きしようとしています。これはパッケージ package-BBB にも含まれています。。
dpkg-deb: サブプロセス paste がシグナル (パイプが切断されました) によって強制終了しました。
以下のパッケージの処理中にエラーが発生しました:
/var/cache/apt/archives/package-AAA*.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

恐らく package-AAA に package-BBB を Replaces するよう指定されていない事が原因で、メンテナのパッケージングミスです。 軽度な場合は再度 upgrade を実行すれば回避できるかもしれません。

駄目な場合は package-BBB を削除すれば回避できるかもしれませんし、余計にややこしい状態になるかもしれません。 急ぎでなければ BTS に投げて修正されるのを待ちましょう。

/var/lib/dpkg/available が壊れた

apt-get update, aptitude update などでは修復できません。
(dpkg が管理する設定ファイルであるため。)

dselect を起動して 2 の update を実行しましょう。

2 の update を実行したら終了してしまってかまいません。

aptitude update したら "E: Dynamic MMap ran out of room" とエラーが出た

sources.list にたくさん書きすぎです。apt-line を減らすか、/etc/apt/apt.conf.d/99cache_limit に

APT::Cache-Limit "100000000";

などと書いておくといいです。

詳しくは man apt.conf 参照。

aptitude upgrade で 400 Bad Request が返る

おそらく HTTP 1.1 を解さない proxy のせいです。debian-user@Org での Jason Gunthorpe 氏の投稿 を要約すると

  1. 診断くん等を利用して、ISP が proxy を利用していることを確認したのち、ISP にゴルァ電。 ISP がソフトウェアをアップグレードしてくれるまで続ける。「(ベンダ名) 逝ってよし!」と叫ぶのも忘れない。 ftp を使うと少しはましな結果になるかもしれない。
  2. acquire::http::pipeline-depth=0 を設定する (see "man apt.conf")

の 2 通りの方法があるようです。

パッケージの FAQ

バグを発見したのでバグレポートを出したい

Debian にバグを報告する方法を読みましょう。

英語が苦手でもエラーメッセージなどを添えて報告すれば多分伝わります。 勇気を出して!

もちろん Debian 固有のバグではないと分かった場合は配布元の方へ報告しましょう。 送る前に同じバグレポートがないかチェックするのを忘れずに。

古いパッケージを入れたい

  • アップグレードしたら新しいパッケージがうまく動かない
  • 少し前のバージョンのパッケージに戻したいけど /var/cache/apt/archives にパッケージが見あたらない

そんな経験はありませんか?そんなあなたに、スナップショットデビアンオルグ!

オフィシャルで過去に提供されていた古いバージョンのパッケージが置かれています。 ローカル (/var/cache/apt/archives) にキャッシュが残っていない場合などは、ここから古いバージョンのパッケージが入手できます。

ここで貴方のお望みのパッケージがきっと見つかるはずです。

Debian では i586 や i686 などに最適化されたパッケージは提供されないの?

linux-imageglibc などの一部を除いて本家では提供される予定はありません。 自分でリビルドしましょう。

pentium-builder をインストールして

$ export DEBIAN_BUILDARCH=i586

などとしておけばパッケージングするときに -mcpu=i586 -march=i586 でコンパイルしてくれます。 こうしてできあがったパッケージは hogehoge_i386.deb ですが、ちゃんと i586 に最適化されています。 また ix86 だけでなく DEBIAN_BUILDARCH=athlon なども指定できます。

大量にリビルドしたい場合は apt-buildapt-src などを使うと便利です。 ソースをダウンロード、パッケージング、インストールという一連の作業を自動でやってくれます。

また ccachedistcc などをうまく使えばコンパイル時間も短縮できます。

パッケージに自分で修正を加えたい

例: xsnow 1.42-1

apt-line に deb-src がなければ追記して

# aptitude update

パッケージのビルドに必要なものをインストール

# aptitude install build-essential devscripts
# aptitude build-dep xsnow

作業するディレクトリに xsnow のソースをダウンロード

$ cd (作業するディレクトリ)
$ aptitude source xsnow

あらかじめローカルに

  • .tar.gz
  • .diff.gz (or debian.tar.gz)
  • .dsc

を用意している場合は

$ dpkg-source -x xsnow-1.42-1.dsc

そして好きなように修正を加えます。

修正作業が終わったら、変更点を changelog に書く

$ cd xsnow-1.42
$ dch -n

そしてパッケージのビルド

$ debuild -us -uc

無事にビルドできたら、パッケージをインストール

# dpkg -i ../xsnow_1.42-1.1_*.deb

すべてのパッケージが対応している訳じゃないですが、環境変数 DEB_BUILD_OPTIONS に指定する事で以下のような操作ができます。

  • nostrip : バイナリを strip しない
  • debug : -g オプションをつけてビルド
  • noopt : -O0 オプションでビルド

man dh_strip も参照してみてください。

なお、特定のアーキテクチャ向けに最適化したい場合は、 Debian では i586 や i686 などに最適化されたパッケージは提供されないの?を参考のこと。

また、aptitude build-dep の代わりに mk-build-deps で作った xsnow-build-deps パッケージをインストールする方法があります。 不要になったビルド依存パッケージを削除する時に便利です。

自作パッケージを作りたい

ほとんどが自動化ツールで生成可能なので、本家マージや配布を考えなければ簡単につくれます。

目的のモノが正常にコンパイルできる環境である、ということを前提に話を進めますので、そのあたりは自分で解決してくださいね。

では、まずパッケージ作成に必要なツールをインストールしてください。

終わったら作業したいディレクトリで tarball を展開します。

$ tar xf hoge-0.1.tar.gz

展開したソースディレクトリに移動。

$ cd hoge-0.1

次は hoge-0.1/debian の雛型をスクリプトによって自動で生成します。

$ dh_make -f ../hoge-0.1.tar.gz

ここで作成するパッケージの種類を聞かれますが、適当に答えましょう。

  • s : 単一のパッケージとして作成
  • i : アーキテクチャ非依存のパッケージとして作成
  • m : 複数のパッケージに分割して作成
  • l : ライブラリのパッケージとして作成
  • k : カーネルモジュールのパッケージとして作成
  • n : カーネルパッチのパッケージとして作成

このままだとパッケージに関する情報のほとんどが空ですが、パッケージは作成できます。 また *.ex というファイルが沢山ありますが、それらは高度なパッケージを作る場合に使用するファイルの雛形です。 使わなければ削除してしまっても問題ありません。

debian/rules は実際に実行されるビルド手順とコマンドを記述したファイルで Makefile をベースとしています。 ビルドしようとしているソフトウェアが autotools (./configure; make するやつ) を採用しているなら、特にすることはありません。 ビルドオプションを変更したい場合は

override_dh_auto_configure:
        dh_auto_configure -- --enable-hoge

のような感じで記述するといいでしょう。

以上でパッケージ作成のための最低限の準備は整ったので、パッケージを構築します。

$ debuild -us -uc

致命的な問題がなければ一つ上のディレクトリに hoge_0.1-1_arch.deb が生成されてます。 が、中身が意図してる状態になっているか確認しときましょう。

$ dpkg -c ../hoge_0.1-1_arch.deb

問題なければ Let's install!

# dpkg -i ../hoge_0.1-1_arch.deb

詳しくは以下を参考に、というか読め。

書籍

新たにパッチなどを当てたのでリビジョンを上げたい

そんな場合にはソースディレクトリで

$ dch -i

changelog の編集を要求されるので、変更点などを書き込んで

$ debuild -uc -uc

とすれば hoge_0.1-2_arch.deb が作れます。 quilt などのパッチ管理ツールも用意されてるので利用しましょう。

hoge のバージョンが 0.1 から 0.2 に上がり、パッケージでもそれを追いかけたい

そんな場合には hoge-0.1 のあるディレクトリに hoge-0.2.tar.gz を置き

$ cd hoge-0.1
$ uupdate -v 0.2 ../hoge-0.2.tar.gz
$ cd ../hoge-0.2
$ debuild -us -uc

で hoge_0.2-1_arch.deb が作れます。

ccache を使って Debian パッケージをビルドするには

debuild (dpkg-buildpackage) は環境変数 PATH を初期化してしまうため、 ${HOME}/.bashrc とかに PATH=/usr/lib/ccache:$PATH と書いても無視されます。
以下のオプションを使用して下さい。

$ debuild --prepend-path=/usr/lib/ccache --preserve-envvar=CCACHE_*

パッケージインストール時の処理について詳しく知りたい

メンテナスクリプト (maintainer scripts) については MaintainerScripts - Debian Wiki (英語) という文書があります。

Debconf についての資料はありますか?

仕様書があります。
また、ukai さんによる資料もあります。

ビルド時に要求される Build-Dep を検索したい

grep-dctrl (dctrl-tools) に含まれている grep-available コマンドを利用してみては。

$ grep-available -s Package -F Build-Depends (パッケージ名) /var/lib/apt/lists/(update で取得したデータ)

参考:
http://lists.debian.or.jp/debian-users/200501/msg00201.html

deb パッケージと rpm などの他のパッケージとの違いが知りたい

Linux/UNIX バイナリパッケージ形式の比較 (原文) という素敵なドキュメントがあります。

udeb ってなに?

インストーラなどに使われる、ドキュメントなどが省略されたパッケージ。
普通の deb と udeb はファイル形式の観点から見れば同じもの。

udeb を作るには?

カーネルイメージの deb を udeb に変換するには kernel-wedge を使います。
その他のパッケージは直接変換はできませんが、ソースからリビルドする際、debian/control に書かれている各パッケージフィールド (Package: ) に、

XC-Package-Type: udeb

行を追加すると、udeb になります。

参考: Chapter 3. D-I components or udebs - Debian Installer internals

unstable から testing にパッケージがなかなか降りてこないんだけど

通常は RC bug がなければ urgency=low の場合で 10 日ほどで testing に入る。 しかし他のパッケージに依存している場合、依存先のパッケージも testing に入ってないと降りてこない。 なので glibc などで RC bug が見つかったりするとほぼ更新が止まる。 どのパッケージがどんな理由で降りてこないのかは Why is package X not in testing yet? で検索できます。

また devscripts に同梱されている grep-excuses でも同じような情報が取り出せます。

$ grep-excuses (パッケージ名)

パッケージのバグをチェックしたい

reportbug パッケージに含まれる querybts コマンドを使うと、BTS をチェックできます。 使い方は、

$ querybts (パッケージ名)

を実行してください。

パッケージ化の要望を出したい

本当にオフィシャルパッケージが存在していないかチェック。
その上で BTS の wnpp package をチェック。 (膨大な量が 1 ページに表示されてしまうのが嫌ならば、 Debian Packages that Need Lovin' をチェック。ITP や O などのタグでフィルタできます。)
BTS の wnpp packageとは開発者の助けを必要としているすべてのパッケージの情報を扱うための BTS 上だけの擬似パッケージ名です。
ITP とあればすでに誰かがパッケージ化の宣言をしています。 ITP したまま放置されていなければ、その内パッケージ化されるでしょう。
RFP とあればすでにパッケージ化の要望が出ています。 もし RFP もなければ、あなたが RFP を出して誰かが作ってくれるのを待ちましょう。
詳しくは作業が望まれるパッケージ参照。
もちろんあなたが作ってもかまいません。 ITP を宣言してパッケージを作って下さい。 その時は wnpp package に対する bug report という形で出します。

当然再配布禁止のソフトウェアや商用ソフトウェアは入りません。 また既に公式パッケージがあるソフトウェアにパッチを当てただけのようなものも入りません。 パッケージ化することができないソフトウェアも見ておきましょう。

パッケージがなかなか更新されないんだけど

主な原因として

  • ソフトウェア側に大きな変更や致命的なバグがあった。
  • パッケージングに大幅な変更を加える予定。
  • サポートしているアーキテクチャでビルドできなかった。
  • メンテナが忙しくて更新作業をする暇がない。
  • 新しいメンテナを募集中。

Mentors ってなに?

Debianパッケージを作った人がパッケージをアップロードして、Debian開発者にスポンサー(後見人)になってもらうサイト。 Debianには入ってない新しいパッケージがあります。

http://mentors.debian.net/

バイナリパッケージは提供していない(転送量過多で停止になった)ので、自分でパッケージをビルドする必要があります。

proposed-updates って何?

これは次のポイントリリースとして提供される予定のパッケージが置かれるところです。

ポイントリリース前テストを手伝う気がある人はどうぞ。

Backports ってなに?

安定版用にテスト版や不安定版のパッケージを再ビルドして提供しています。

使用するにはapt-lineに以下を追加。

deb http://ftp.jp.debian.org/debian stable-backports main contrib non-free
deb-src http://ftp.jp.debian.org/debian stable-backports main contrib non-free

詳細は 公式 WikiDebian Backports - Instructions 参照。

Experimental ってなに?

リスクが大きく、unstable に入れる前に実験をしたいソフトウェアがあります。

使用するには以下の apt-line を追加

deb http://ftp.jp.debian.org/debian experimental main contrib non-free
deb-src http://ftp.jp.debian.org/debian experimental main contrib non-free

さらに -t オプションで experimental を明示する必要があり。

aptitude show hogehoge するとなんかいっぱい表示されるんだけど

5.6 フィールドのリスト参照。

仮想パッケージやダミーパッケージってなに?

仮想パッケージ (Virtual package) は実パッケージが存在しないパッケージのこと。 virtual section に属します。 依存関係を柔軟に設定するために用意されているみたい。

ダミーパッケージ (メタパッケージ) は中身が Changelog や リンク提供のみの空パッケージのこと。 パッケージの分割等で変更された依存関係に互換性を持たせるため用意されたりします。 基本的には削除しても動作に問題は出ません。

インストール済みのソフトウェアをパッケージに戻したい

dpkg-repack を使いましょう。 一度パッケージからインストールしたソフトウェアを、再びパッケージに戻してくれます。 またインストール後に設定ファイルの編集等をした場合、その変更点を受け継いだパッケージが生成されます。

# dpkg-repack (パッケージ名)

以前あったパッケージが見当たらないのだけど

アップストリームやパッケージメンテナによるメンテナンス状況やその他代替パッケージの登場などにより、 古くなったパッケージは適宜アーカイブから削除されます。

aptitude ではインストール済みパッケージがアーカイブより削除された場合、 「廃止された、またはローカルで作成されたパッケージ」 欄に表示されます。

リポジトリから削除されたパッケージを知りたい

削除された理由も一緒に書いてあります。

リポジトリに追加されたパッケージを知りたい

人気コンテストへの参加

Debian Popularity Contest でパッケージの利用状況等を集計しています。 この結果は Orphan されたパッケージを QA Team で保守するかどうか、インストール CD に含めるパッケージを決める時等に利用されます。 参加するには popularity-contest をインストールするだけです。

# aptitude install popularity-contest

Microsoft Windows 上でパッケージを操作したい

7-Zip などがあります。 Debian パッケージは debian-binary (ただのプレーンテキスト), control.tar.gz, data.tar.gz の 3 つを ar でアーカイブしたものなので、 展開するだけなら ar 形式に (更に tgz 形式にも) 対応したアーカイバソフトでできるはずです。

1.10.24 以降の dpkg は gzip を含めて様々な圧縮フォーマットにも対応しているため、 ar 展開後の control.tar や data.tar は gzip 圧縮されているとは限りません。 (dpkg-deb(1) の -Zcompress_type オプションを参照してください。)



*1 これを指定しないと、全ての apt-line のうち最新バージョンが優先されるため、全てのパッケージが testing や unstable になってしまう
*2 404 Not Found

トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2013-05-11 (土) 09:58:19 (1201d)