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


パッケージシステムの FAQ

aptitude の特長

参照:

apt の使い方を知りたい

APT HOWTO という素敵なドキュメントがあります。

aptitude の使い方を知りたい

aptitude ユーザマニュアルなどがあります。

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

参照:

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

主なエラー

1. gnupg パッケージがない

W: GPG error: http://ftp.jp.debian.org unstable Release: Could not execute /usr/bin/gpgv to verify signature (is gnupg installed?)

secure apt は GNU Privacy Guard の公開鍵暗号処理を 利用しているため、gnupg パッケージ をインストールする必要があります。

# aptitude install gnupg

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

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

/etc/apt/trusted.gpg はありますか? なければ手動でコピーしてください。

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

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

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/apt/debian-archive.gpg /etc/apt/trusted.gpg

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

他の鍵のありかとしては、 ftp-master の "Archive signing key" などがあります。
例えば、2007 年 (etch) のものは、

http://ftp-master.debian.org/archive-key-4.0.asc

です。導入方法は、

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

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

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

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

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

上記のコマンドではパイプを使用するので、sudo を使いたいときは、(sudo(8) 参照)

$ sudo sh -c "gpg --armor --export (鍵 ID) | apt-key add -"

su を使いたいときは、

$ su -c "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 が yum コマンドに相当します。 rpm コマンドで管理する場合と手間も似たようなものです。

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

具体例を挙げると、dpkg コマンドでバージョン 4.50-1 の lv パッケージをインストールするには

の中でインストール済みのパッケージを除く、すべてのパッケージファイル (*.deb) が必要です。

ファイルを (例えばカレントディレクトリに) 用意できたら、まず lv が依存しているパッケージ群を順番にインストールします。 インストールでは、パッケージ名 (libc6) ではなくパッケージのファイル (例:libc6_2.3.2.ds1-22_i386.deb) を指定します。

# dpkg -i ./libc6_2.3.2.ds1-22_i386.deb
# dpkg -i ./libncurses5_5.4-7_i386.deb

最後に lv をインストールします:

# dpkg -i ./lv_4.50-1_i386.deb

同時にインストールしてしまってもオッケーですが順序に注意のこと。

# dpkg -i ./libc6_2.3.2.ds1-22_i386.deb ./libncurses5_5.4-7_i386.deb ./lv_4.50-1_i386.deb

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 -S `which (コマンド名)`
例)
$ dpkg -S `which ps`
procps: /bin/ps
# aptitude install dlocate
# update-dlocatedb
$ dlocate (コマンド名やファイル名)

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

http://www.jp.debian.org/distrib/packages#search_contents

パッケージ名と description しか検索しないので見つからないかも。

$ apt-cache search (コマンドやファイル名、関連するキーワードなど)

auto-aptapt-file などがある。

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

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 などの maintainer scripts を取り出したい場合は

$ dpkg -e (パッケージファイル名) (展開するディレクトリ)
例)
$ dpkg -e w3m_0.5.1-3_i386.deb ~/w3m_control

binutils に入っている ar を使うと、構成ファイルと maintainer scripts の両方が取り出せる。
control.tar.gz には maintainer scripts, チェックサムなど、data.tar.gz には構成ファイルが入っている。

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

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

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

例:

# aptitude install apache=1.3.26-0woody3

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

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

/etc/apt/sources.list には testing や unstable の apt-line も入れておく必要があります。 忘れずに。

また stable な環境などで libc6 などの根幹にかかわるパッケージも依存関係でアップグレードされる場合、 安易に (Y) を選ぶと大変なことになるのでよく考えてから。 どんどん新旧のパッケージが混ざっていつの間にかなんちゃって unstable な環境とかになってしまいます。

99target を使う

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

APT::Default-Release "stable";

と書く。

# aptitude install (パッケージ名)

で stable のパッケージが入る。 testing/unstable から借りる場合はそれぞれ

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

preferences を使う

上記の /etc/apt/apt.conf.d/99target を作るかわりに、/etc/apt/preferences へ

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

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

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

と書く。リリース間は空行で分離する。こちらを用いることの利点は、

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

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

Pin-Priority意味
0インストールしない
1-99指定すればインストールできるが、アップグレードの対象にはならない
100現在インストールされているパッケージの priority
101-989指定してインストールしたものも、アップグレードの対象になる
(500)現在インストールされてないパッケージの priority
(989)apt-pin の default priority
990apt-get の --target-release (-t) オプションが指定された際に利用される priority
1000以上ダウングレードしてでもそのパッケージをインストールさせる

このやりかたは、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 くらいまで項目を追加しておくと良い。

rebuild する

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

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

オススメは pin を使った方法。 /etc/apt/preferences に留めておきたいパッケージ名とバージョンを

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

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

のように書いておく。

その他には

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

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

/etc/apt/preferences に

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

と書いて

# aptitude dist-upgrade

を実行してください。
unstable から testing にダウングレードするには a=stable を a=testing にして下さい。
但し、特定のパッケージ、またはシステム構成によっては不安定な状態になるかもしれません。
以下の注意点も読んで下さい。

ダウングレード時の注意点

base パッケージの構成変更等によって、システムが不完全な状態になってしまう場合があります。環境が破壊された状況からの修復に自信が無い場合、事前に完全なバックアップを作成しておくことをお勧めします。

ダウングレード時のトラブル事例 ( testing -> stable )

sarge -> woody か etch -> sarge での事例です。どちらかはわかりません。

testing -> stable にダウングレードを行う際に、 /bin/rm が含まれるパッケージが stable -> testing で変更されており、 下記の問題が発生した。

  1. testing で /bin/rm を含むパッケージが削除される
  2. rm, cp, ln 等の基本的なコマンドが削除され、パッケージ管理中に実行される preinst, postinst 等の maintainer スクリプトが正常に動作しなくなる
  3. ダウングレードが不完全な状態で中断される

どのパッケージを 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 もあります。

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

# apt-get check

recommends なパッケージも一緒にインストールしたい

aptitude を使えば recommends なパッケージも一緒にインストールされます。

# aptitude install (パッケージ名)

インストールして欲しくない場合は

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

設定は aptitude をフルスクリーンモードで起動して

# aptitude

F10 → Options → Dependency handling で。

削除したパッケージに関連したパッケージを削除したい

インストール時に aptitude を使いましょう。 依存関係で芋蔓式にインストールされたパッケージも一緒に削除できます。

もう遅い、という人は依存関係から孤立したパッケージを探すにはを読んで、手動で検索して削除しましょう。 そして次から aptitude を使うように。

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

aptitude は自動的にインストールされたものか、指定してインストールされたものかを独自で管理しています。

# aptitude unmarkauto パッケージ名

で自動的にインストールしたものではないと設定できます。
aptitude を使う場合は apt-get との混用を避けるべきです。

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

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

$ dpkg --get-selections > list

でパッケージ構成を取得、新規マシンにコピーし、

# dpkg --set-selections < list
# apt-get -f install

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

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

# 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' 

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

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

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 通りの方法があるようです。

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

deb を置いたディレクトリで dpkg-scanpackages

$ dpkg-scanpackages ./ /dev/null | gzip -c9 > Packages.gz 

でもいいけど

$ apt-ftparchive packages . | gzip -c9 > Packages.gz
$ apt-ftparchive sources . | gzip -c9 > Sources.gz

の方がムトゥ神推奨。apt-ftparchive は apt-utils パッケージに入っている。
次に sources.list に

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

例)
deb file:/usr/src/ ./

を追加して、aptitude update して aptitude install (パッケージ名) で完了。

参考:
/usr/share/doc/apt/offline.html

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

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

apt の GUI フロントエンドはありますか?

synapticgnome-aptpackagesearchkpackage などがあります。

パッケージの更新を通知して欲しい

apt-watch を使いましょう。
cron-apt と組み合わせて使えば cron-apt で情報を取得し、更新があれば apt-watch が更新した事を通知してくれます。
類似パッケージに apticron などがあります。

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

cron-apt を使いましょう。
ただしデフォルトではダウンロードのみされるように設定されてます。 /etc/cron-apt/action.d/3-download の upgrade から "-d" オプションを取り除き、debconf や apt.conf などに APT::Get::Assume-Yes "true" などを設定しておきましょう。 危険なので stable でセキュリティ Fix のみするような用途以外にはオススメしません。

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

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 なら該当パーテョションをマウントしていない状態で

# e2fsck -cf /dev/hda1

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

Reiserfs なら Bad block handling in ReiserFS を参照。 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 に投げて修正されるのを待ちましょう。

ttf-opensymbolのエラーが出てパッケージのインストールが先に進まない

この項目は etch の新規インストール限定です。

フォントがあるディレクトリのタイムスタンプがおかしいと fontconfig の更新に失敗して、 それ以降のパッケージのインストールが進まなくなります。

これを解消するには以下のようなコマンドでディレクトリのタイムスタンプを更新すれば先に進みます。

$ sudo find /usr/share/fonts/ -type d -exec touch {} \;
$ sudo find /usr/X11R6/lib/X11/fonts/-type d -exec touch {} \;
$ sudo find /var/lib/defoma/fontconfig.d/ -type d -exec touch {} \;
$ sudo find /usr/local/share/fonts/ -type d -exec touch {} \;
$ sudo apt-get -f install

パッケージの FAQ

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

Debian にバグを報告する方法を読みましょう。
英語が苦手でもエラーメッセージなどを添えて報告すれば多分伝わります。
勇気を出して!

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

apt-line の proposed-updates って何?

これはリリース後に行われた修正を取り込んだパッケージを暫定的に置く所で、 原則次のリリース時には本体に取り込まれます。
従ってこれは Debian の "正式" リリースではありません。
主にセキュリティ Fix の為に設置されますが、あくまで開発者向けの暫定的なものなので 突然パッケージがなくなったりして依存関係に問題が出ることもあり、注意が必要です。 また、パッケージが十分にレビューされていない可能性もあるので、 一般のユーザは取り込まない方が良いでしょう。
この "リリース" というのはメジャーリリースではなくマイナーリリースのことで、 例えば、sarge (3.1) ならば 3.1r0 などの r0 というリビジョンが振られます。

Debian - News: Debian Security Support in Place, July 8th, 2005 では、導入に対する警告が行われました。

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

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

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

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

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

kernel-image や glibc などの一部を除いて本家では提供される予定はありません。 自分で rebuild しましょう。 pentium-builder をインストールして

$ export DEBIAN_BUILDARCH=i586

などとしておけばパッケージングするときに -mcpu=i586 -march=i586 でコンパイルしてくれます。 こうしてできあがったパッケージは hogehoge_i386.deb ですが、ちゃんと i586 に最適化されています。 また ix86 だけでなく DEBIAN_BUILDARCH=athlon なども指定できます。 大量に rebuild したい場合は apt-build や apt-src などを使うと便利です。 ソースをダウンロード、パッケージング、インストールという一連の作業を自動でやってくれます。 また ccachedistcc などをうまく使えばコンパイル時間も短縮できます。

参考
http://julien.danjou.info/article-apt-build.html

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

例:xsnow 1.42-1

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

# apt-get update

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

# apt-get install build-essential devscripts
# apt-get build-dep xsnow

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

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

あらかじめローカルに .tar.gz .diff .dsc を用意している場合は

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

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

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

$ cd xsnow-1.42
$ dch -n

そしてパッケージの build

$ debuild -us -uc

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

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

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

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

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

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

ほとんどが自動化ツールで生成可能なので、本家マージや配布を考えなければ簡単につくれます。
大抵のソフトウェアは普通にコンパイルする手間とさほど変わらないかと。

とりあえず以下をインストール

配布を考えているなら以下もインストール

とりあえず目的のモノが正常にコンパイルできる環境である事が前提です。 配布を考えているなら自分の名前やメールアドレスを指定しておきましょう。

$ export DEBEMAIL="hoge@foge.ne.jp"
$ export DEBFULLNAME="hoge fuge"

また gnupg など署名をつける場合にはあらかじめ鍵を作っておく必要があります。

まず作業したいディレクトリで tarball を展開します。

$ tar xvfz hoge-0.1.tar.gz

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

$ cd hoge-0.1

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

$ dh_make

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

このままだとパッケージに関する情報のほとんどが空ですが、このままでもパッケージは作成できます。 でも配布を考えているなら最低限、ライセンスや依存関係等々を debian/ 下にある各種ファイルに書き込みましょう。

記述の仕方は既存のパッケージを参考にするといいでしょう。 また *.ex というファイルが沢山ありますが、それらは高度なパッケージを作る場合に使用するファイルの雛形です。 使わなければ削除してしまっても問題ありません。 以上でパッケージ作成のための最低限の準備は整ったので、パッケージを構築します。

$ debuild

lintian もしくは linda が debian ポリシーに適合しているかチェックしてくれるので、表示された結果を元にエラー箇所を潰していけます。エラーの詳細を調べたいときは、

$ lintian -i hoge_0.1-1_arch.changes

するといいでしょう。
致命的な問題がなければ一つ上のディレクトリに 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

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

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

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

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

書籍

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

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

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

仕様書があります。
また、ukai さんによる資料もあります。
第8回東京エリアDebian勉強会: debconfの使い方

build 時に要求される 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 パッケージは kernel-wedge でつくれます。

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 をチェック。 BTS の wnpp packageとは開発者の助けを必要としているすべてのパッケージの情報を扱うための BTS 上だけの擬似パッケージ名です。 ITP とあればすでに誰かがパッケージ化の宣言をしています。 ITP したまま放置されていなければ、その内パッケージ化されるでしょう。 RFP とあればすでにパッケージ化の要望が出ています。 もし RFP もなければ、あなたが RFP を出して誰かが作ってくれるのを待ちましょう。 詳しくは作業が望まれるパッケージ参照。

もちろんあなたが作ってもかまいません。 ITP を宣言してパッケージを作って下さい。 その時は wnpp package に対する bug report という形で出します。

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

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

主な原因として

Experimental ってなに?

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

http://packages.debian.org/experimental/

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

deb http://近くのリングサーバ/archives/linux/debian/debian experimental main
deb-src http://近くのリングサーバ/archives/linux/debian/debian experimental main

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

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

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

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

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

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

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

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

以下を参照

http://ftp-master.debian.org/removals.txt

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

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

以下を参照

http://ftp-master.debian.org/testing/hints/vorlon

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

unstable に追加されたパッケージを知りたい

以下を参照

http://packages.debian.org/unstable/newpkg_main
http://packages.debian.org/unstable/newpkg_contrib
http://packages.debian.org/unstable/newpkg_non-free

人気コンテストへの参加

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

# aptitude install popularity-contest

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

Undeb, 7-Zip などがあります。


トップ   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS