[ 前のページ ] [ 目次 ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ A ] [ 次のページ ]


Debian GNU/Linux 3.1 (`sarge') リリースノート (IA-64 用)
第 4 章 - 以前のリリースからアップグレードする


4.1 アップグレードの準備

システムをアップグレードする前に、完全なバックアップを取っておくよう 強くお勧めします。少なくとも、 失いたくないデータや設定情報だけでもバックアップしておきましょう。 アップグレードのツールや処理はきわめて信頼性の高いものですが、 アップグレードの最中にハードウェア障害が起こると、 システムに大きなダメージを与えることがありえます。

バックアップしたくなるであろう主な対象としては、/etc/var/lib/dpkg の中身、dpkg --get-selections "*" (引用符を忘れてはいけません) の出力などでしょう。

アップグレードの過程では、/home ディレクトリ以下は一切変更されません。とはいえ、 (Mozilla やいくつかの KDE アプリケーションなどのように) ユーザが初めて新しいバージョンのアプリケーションを起動するときに、 既存のユーザ設定を新たなデフォルト値で上書きしてしまうものがあるのも事実です。 万一に備えて、ユーザのホームディレクトリにある隠しファイルと隠しディレクトリ (いわゆる「ドットファイル」) をバックアップしておくのがよいでしょう。 古い状態に戻したり、再度設定する場合に役立つはずです。 ユーザにもこのことについて知らせておいてください。

アップグレードの前には、その予定をすべてのユーザに知らせるとよいでしょう。 しかしシステムに SSH などでアクセスしてきているユーザは、 アップグレードの最中にもそうとは気づかず、 作業を続行してしまうかもしれません。 万一の用心をしたければ、アップグレードの前に ユーザのパーティション (/home) をバックアップして、 アンマウントしてしまいましょう。 同時にカーネルもアップグレードする場合を除いて、 通常は再起動は必要ないでしょう。

ディストリビューションのアップグレードは、 ローカルのテキストモードの仮想コンソール (あるいは直接接続されたシリアル端末) から行うか、 リモートなら ssh 接続経由で行いましょう。

重要! telnetrloginrsh を用いてアップグレードをしては いけません。 アップグレードマシンの xdmgdmkdm などが管理している X セッションからのアップグレードも行うべきではありません。 これらのサービスはアップグレードの最中に切断されてしまう可能性が高く、 するとアップグレード途中のシステムへの 接続が不可能になってしまう からです。

あらゆるパッケージのインストール処理はスーパーユーザ特権で実行 されなければならないため、必要なアクセス権を得るために root として ログインするか susudo を使ってください。


4.2 システムの状態をチェックする

この章で述べられているアップグレード手順は、"純粋な" woody システムからのアップグレード用です。システムが woody の最新 リリースにアップデート済であるものと想定しています。そうではなかったり、 アップグレード済みかどうか不明なら、woody システムのアップグレード, 第 A.1 節 内の指示に従っ てください。

また、aptitude の woody 版がインストール済みである とも想定しています。次のように実行してインストール済みかどうかを調 べることができます:

     $ dpkg -l aptitude

出力行が "i" で始まっていなければwoody 版 aptitude のインストール, 第 A.2 節 の指示 に従ってアップグレードを始める前に、インストールしておかなければなりま せん。


4.2.1 APT の pin 機能を無効にする

特定のパッケージを安定版以外 (テスト版など) のディストリビューションから インストールするように APT を設定しているなら、当該パッケージが新しい安定 版リリース内のバージョンにアップグレードできるように、 (/etc/apt/preferences 内に保存されている) APT の pin 設定を 変更する必要があるかもしれません。APT の pin 機能に関するより詳しい情報 は、apt_preferences(5) にあります。


4.2.2 パッケージの状態をチェックする

アップグレードに使う手段に関係なく、まず全パッケージの状態を調べ、 全パッケージがアップグレード可能な状態にあることを確認するよう推奨し ます。次のコマンドは、インストールが中断していたり設定に失敗したパッ ケージや、何らかのエラー状態にあるパッケージを表示します:

     # dpkg --audit

dselectaptitude、あるいは次のようなコマンドを 使ってシステムの全パッケージの状態を検査することもできます:

     # dpkg -l | pager

または

     # dpkg --get-selections > ~/curr-pkgs.txt

アップグレード前に、あらゆる hold 状態を解除しておいたほうがよいで しょう。アップグレードに不可欠なパッケージが hold 状態にあるなら、 アップグレードに失敗するでしょう。 hold 状態にあるパッケージを記録するのに、aptitudeapt-getdselect とは異なる手法を用いることに注意してください。aptitude では、以下のように実行して hold 状態にあるパッケージを検出できます:

     # aptitude search "~ahold" | grep "^.h"

apt-get でどのパッケージが hold 状態にあるのかを調べたければ、 以下のように実行してください:

     # dpkg --get-selections | grep hold

パッケージをローカルに変更したり再コンパイルしており、しかも名前を 変えていなかったりバージョンに単位を付加していないなら、アップグレー ドしないよう hold 状態にしておかなければなりません。 パッケージの "hold" 状態を aptitude で変更するには、以下のように実行 してください ("hold" 状態を解除するには holdunhold で置き換え ます):

     # aptitude hold package_name

修正が必要なことがあるなら、ソースリストのチェック, 第 A.3 節 で説明されている ように sources.list が woody を指定したままにして おくべきです。


4.2.3 非公式なソースとバックポート

自分のシステムに非 Debian パッケージがあるなら、依存関係の衝突の ためアップグレード中に削除されるかもしれないことに注意すべきです。 当該パッケージが /etc/apt/sources.list に特別なパッケージ アーカイブを追加することでインストールされたのなら、そのアーカイブが sarge 用にコンパイルされたパッケージも提供しているかをチェックし、 Debian パッケージ用のソース行と一緒にそのソース行も適切に修正すべきです。

自分の woody システムに、Debian に存在するパッケージの 非公式にバックポートされた "新" バージョンをインストールしているユーザも いるでしょう。そのようなパッケージはファイルの衝突を引き起こすことにより、 アップグレード中に問題を引き起こす場合がほとんどでしょう [1]。 ファイル衝突が発生したときの対処方法については、アップグレード中の注意点, 第 4.4.5 節 にいくつかの情報があります。


4.3 APT の取得先 (ソース) の準備

アップグレードを始める前に、apt の設定ファイル /etc/apt/sources.list を編集して、 パッケージの取得先を決める必要があります。

apt は、"deb" 行にあるすべてのパッケージを見比べ、 最も大きなバージョン番号のパッケージをインストールします。 同じパッケージが取得可能な場合は、先に現れた行を優先します (つまり、複数のミラーを指定している場合は、 最初にローカルのハードディスクを、次に CD-ROM を、 最後に HTTP/FTP ミラーを指定するといいでしょう)。

一つのリリースを指定するのに、コードネーム (woody や sarge) と状態名 (旧安定版、安定版、テスト版、不安定版) の両方ともがよく使われています。 コードネームによる指定は、新しいリリースが出た時にびっくりせずに済むという 利点があるため、ここではコードネームを使っています。もちろんこれは、自分 でリリースアナウンスを注視する必要があることを意味してはいません。代わり に状態名を使っているなら、リリースされた直後に利用可能なパッケージの 更新が急に増えたことに気づくでしょう。


4.3.1 APT の Internet ソースの追加

デフォルトの設定では、メインの Debian インターネットサーバを 使ってインストールするようになっています。ですがここでは、 /etc/apt/sources.list を編集して、 他のミラー (できればネットワーク的に最も近いミラー) を使うようにするほうがよいでしょう。

Debian の HTTP / FTP ミラーのアドレスは、http://www.debian.org/distrib/ftplist を参照してください。 一般には HTTP ミラーのほうが FTP ミラーよりも高速です。

例えば、一番近くにある Debian ミラーが http://mirrors.kernel.org/debian/ だったとしましょう。 このミラーをウェブブラウザや FTP プログラムで見てみると、 main などのディレクトリが以下のように構成されていることがわかります。

     http://mirrors.kernel.org/debian/dists/sarge/main/binary-ia64/...
     http://mirrors.kernel.org/debian/dists/sarge/contrib/binary-ia64/...

このミラーを apt で使うには、次の行を sources.list ファイルに追加します。

     deb http://mirrors.kernel.org/debian sarge main contrib

`dists' は書かなくても暗黙のうちに追加されます。 そしてリリース名の後の引き数がそれぞれ用いられ、 複数のディレクトリの各々のパス名に展開されます。

これらの新たなソースを追加したら、それまでの sources.list 中の "deb" 行の先頭に シャープ記号 (#) を置き、それらを無効にしてください。

インストールに必要なパッケージのうち、 ネットワークから取得されたものは、 /var/cache/apt/archives ディレクトリ (およびダウンロード中のものは partial/ サブディレクトリ) に置かれます。したがって、インストールを行う前には、 十分な領域があるかどうか確認しなければなりません。 割に大きめのインストールを行う場合には、 ダウンロードデータとして少なくとも 300MB 程度を考慮しておきましょう。


4.3.2 APT のローカルミラーソースの追加

HTTP や FTP のパッケージミラーを使うのではなく、 ローカルディスク (多分 NFS マウントされたもの) にあるミラーを使うよう、 /etc/apt/sources.list を変更したいこともあるかもしれません。

例えばパッケージのミラーが /var/ftp/debian/ にあり、 main などのディレクトリが次のように配置されているとします。

     /var/ftp/debian/dists/sarge/main/binary-ia64/...
     /var/ftp/debian/dists/sarge/contrib/binary-ia64/...

これを apt から使うには、次の行を sources.list ファイルに追加します。

     deb file:/var/ftp/debian sarge main contrib

`dists' は書かなくても暗黙のうちに追加されます。 そしてリリース名の後の引数がそれぞれ用いられ、 複数のディレクトリの各々のパス名に展開されます。

これらの新たなソースを追加したら、それまでの sources.list 中の "deb" 行の先頭に シャープ記号 (#) を置き、それらを無効にしてください。


4.3.3 APT の CD-ROM/DVD ソースの追加

CD だけでインストールをしたい場合は、 /etc/apt/sources.list 中の "deb" 行の先頭に シャープ記号 (#) を置き、それらを無効にしてください。

CD-ROM ドライブをマウントポイント /cdrom にマウントすることを許可している行が /etc/fstab にあるかどうかを確認してください (apt-cdrom を使う場合は、マウントポイントを /cdrom 以外にはできません)。 例えば /dev/hdc が CD-ROM ドライブなら、 /etc/fstab には次のような行が必要です。

     /dev/hdc /cdrom auto defaults,noauto,ro 0 0

第 4 フィールドの defaults,noauto,ro の間には スペースがあってはいけません。

これが正しく機能しているか調べるには、 CD を挿入して以下を実行してみてください。

     
     # mount /cdrom    # マウントポイントに CD をマウントします
     # ls -alF /cdrom  # CD のルートディレクトリを表示します
     # umount /cdrom   # CD をアンマウントします

問題がなければ

     # apt-cdrom add

を、Debian Binary CD-ROM それぞれに対して実行してください。 各 CD に関するデータが APT のデータベースに追加されます。


4.4 パッケージのアップグレード

Debian GNU/Linux リリース間のアップグレード方法のお勧めは、 パッケージ管理ツール aptitude を用いる方法です。 このツールはパッケージに関する判断を apt-get よりも安全に行います。

まず、必要なパーティションが read-write モードで マウントされていることを忘れずに確認しましょう (特にルートと /usr の各パーティション)。 以下のようなコマンドラインが使えます。

     # mount -o remount,rw /mountpoint

次に、(/etc/apt/sources.list 内の) APT ソース記述が "sarge" か "stable" のいずれかを指定している ことを念入りにチェックすべきです。 注意: CD-ROM のソース行は "unstable"; を指定していることがよく あります。これは混乱の元ですが、変更してはいけません

ここで強くお勧めしたいのですが、 /usr/bin/script プログラムを使って、 このアップグレード作業の記録を取るようにしましょう。 こうすれば何らかの問題が生じたときに、 何が起こったかを記録しておくことができ、 バグ報告の必要が生じた場合に、その正確な情報を提供できます。 記録を開始するには次のように入力します。

     # script -a ~/upgrade-to-sarge.typescript

typescript ファイルは /tmp/var/tmp のような一時ディレクトリには置かないでください (これらのディレクトリのファイルは アップグレードや再起動の際に削除されることがありますから)。

typescript はまた、スクロールしてスクリーンから消えた情報を見ること ができるようにもしてくれるでしょう。(alt-F2 を使って) 2 番 の仮想コンソールに切り替えて、ログインしてから less ~root/upgrade-to-sarge.typescript と実行すれば 当該ファイルを見ることができます。

アップグレード完了後に script を停止するには、プロンプトから exit と入力してください。


4.4.1 パッケージリストの更新

まず、新規リリース用として入手可能なパッケージの一覧を取得する必要が あります。次のように実行してください[2]:

     # apt-get update

4.4.2 aptitude のアップグレード

アップグレード中の複雑な依存関係の解決には、apt-get や woody の aptitude よりも、sarge 版の aptitude のほうが優れていることがアップグレードのテスト中に 判明しました。 したがって、次のように実行してまずアップグレードすべきです:

     # aptitude install aptitude

発生した変更点の一覧が表示され、承認を求めてくるでしょう。 承認する前に提示された変更点、特にアップグレードによって削除 されるであろうパッケージに注意を払ってください。

非常に多くのパッケージが削除対象としてリストアップされてしまう場合があります。 この場合、aptitude とともに事前にアップグレードするパッケージを選択しておくと、 リストアップされるパッケージを減らせるかもしれません。 わかりやすい例を挙げてみましょう - すでに KDE がインストールされたシステムの アップグレードテスト中に、大量の KDE パッケージや perl が削除対象になることがありました。 ここでは install aptitude ではなく install aptitude perl とすると、うまくいくことがわかりました。


4.4.3 doc-base のアップグレード

doc-base をインストール しているなら、残りのシ ステムに先立ってアップグレードしなければなりません。この理由は、同時 に perl がアップグレードされると失敗する可能性があるからです。同パッ ケージがインストールされているかどうかを知るには、次のように実行して ください:

     # dpkg -l doc-base

を実行すれば確認できます。

"i" で始まる行が出力されればインストールされているので、 以降の作業を行う前にアップグレードしなければなりません。

     # aptitude install doc-base

4.4.4 残りのシステムのアップグレード

さて、アップグレードの主要部分を続行する準備が整いました。 以下のコマンドを実行してください:

     # aptitude -f --with-recommends dist-upgrade

これによってシステムの完全なアップグレードを行います。 すなわちすべてのパッケージの最新版を入手し、 パッケージのリリースが変わったことによって生じる 依存関係の変更すべてを解決します。 必要に応じて、新しいパッケージ (通常は更新版のライブラリや、 名前の変わったパッケージ) をインストールしたり、 衝突している古いパッケージ (console-tools-libs など) を削除したりもします。

CD-ROM のセットからアップグレードする場合には、 アップグレード作業の最中に CD を交換するよう、 数回指定されることになります。 同じ CD を複数回入れなければならないかもしれません。 これはパッケージ間の相互依存関係のせいで、 これらのパッケージが別々の CD に入っていることもあるからです。

現在インストールされているパッケージの更新版が、 他のパッケージのインストール状態を変更しなければならないような場合には、 そのパッケージは現在のバージョンのままになります ("held back" と表示されます)。 この状態は、aptitude でこれらのパッケージをインストール対象として選択するか、aptitude -f install package を試すかのどちらかで解決できます。

--fix-broken (または単に -f) オプションを与えると、 apt はシステムに存在する壊れた依存関係を修復しようとします。 apt は、壊れたパッケージ依存関係がシステムに存在するのを 許しません。


4.4.5 アップグレード中の注意点

aptitudeapt-getdpkg の操作中に次のようなエラーが出た場合、

     E: Dynamic MMap ran out of room

デフォルトのキャッシュ容量では不十分だということです。これを解決するには、 /etc/apt/sources.list から不要な行を削除もしくはコメントアウトするか、 キャッシュサイズを増やします。キャッシュサイズを増やすには、 /etc/apt/apt.confAPT::Cache-Limit を設定します。 以下のコマンドを実行すれば、アップグレードするには十分な値が設定されます:

     # echo 'APT::Cache-Limit "12500000";' >> /etc/apt/apt.conf

ここでは、/etc/apt/apt.conf ファイル内にまだこの値を設定していない場合を想定しています。

場合によっては衝突や依存関係のループのために、 APT の APT::Force-LoopBreak オプションを有効にして、 必須パッケージを一時的に削除しなければならないかもしれません。 その場合 aptitude はこのことを警告してアップグレードを中断します。 aptitude のコマンドラインに -o APT::Force-LoopBreak=1 を指定すれば、 この状態を回避できます。

システムの依存関係の構造が非常に混乱していて、 手動での介入が必要となることもあります。 通常これは aptitude を用いるか、あるいは

     # dpkg --remove package_name

として、目ざわりなパッケージを消す作業になります。 または次の作業でもよいかもしれません。

     # aptitude --fix-broken install
     # dpkg --configure --pending

極端な場合には、コマンドラインから

     # dpkg --install /path/to/package_name.deb

のように入力して、再インストールしなければならないかもしれません。

「純粋な」woody システムからのアップグレードでは、 ファイルの競合は起こらないはずですが、 非公式なバックポートパッケージをインストールしているなら起こるかもしれません。 ファイルの競合が起こると、次のようなエラーになります:

     Unpacking replacement <package-foo> ...
     dpkg: error processing <package-name-for-foo> (--unpack):
      trying to overwrite `<some-file-name>',
      which is also in package `<package-bar>

ファイルの競合を解消するには、 エラーメッセージの最後の行に表示されたパッケージを強制的に削除します:

     # dpkg -r --force-depends package_name

問題が修正できたら、先に示したように aptitude コマンドを繰り返し入力すれば、 アップグレードを再開できます。

アップグレードの最中に、 いくつかのパッケージの設定・再設定に関する質問が表示されます。 /etc/init.d/etc/terminfo ディレクトリに置かれるファイルと /etc/manpath.config に関しては、 パッケージメンテナのバージョンに置き換えるようにしてください。 システムの整合性を保つためには `yes' と答えることが必要になります。 古いバージョンも .dpkg-old という拡張子で 保存されていますので、戻すのはいつでもできます。

どうすればよいかわからなくなったら、 そのパッケージやファイルの名前を書き留めておいて、 その問題解決は後回しにしましょう。 typescript ファイルを検索すれば、 アップグレードの最中に画面に表示された情報を見直すこともできます。


4.5 リブート前にすべきこと

aptitude dist-upgrade が終了したら、 「公式」にはアップグレードは終了したことになります。 しかし次にリブートする前に、 面倒を見てやらなければならないことがいくつかあります。

X Window System 関連のパッケージの アップグレードに関する詳しい情報は、 /usr/share/doc/xfree86-common/README.Debian-upgrade.gz を読んでください。これは以前の Debian リリースすべてのユーザに 当てはまります。要するに、読め、ということです。


4.5.1 カーネルのアップグレード

Linux カーネルは、以上の手続きによっては更新されません。 そのようにしたい場合は、kernel-image-* パッケージの どれか一つをインストールするか、 カスタマイズしたカーネルをソースからコンパイルするかします。

Linux カーネルの古い安定版である 2.4 系列を使っているのなら、より優れた ハードウェア対応と改良されたパフォーマンスを求めて、2.6 系列のカーネルに アップグレードしたくなるかもしれません。

しかし、woody から sarge へのアップグレード中に、 2.6 系カーネルにアップグレードするのはお勧めしません。 2.6 系へのアップグレードに関するいくつかの問題が、2.6 系カーネルへのアップグレード, 第 5.2 節 に記載されています。

カーネルをアップグレードするには、 まず初めにお使いのサブアーキテクチャに最適なカーネルを選択する必要があります。 インストールできるカーネルの一覧は、以下のコマンドで得られます。

     # apt-cache search ^kernel-image

インストールするカーネルイメージが決まったら、aptitude install でインストールします。新しいカーネルがインストールされたら、 それを有効にするためにリブートしてください。

woody (と、それ以前のリリース) のインストールシステムでは、 お使いのシステムにカーネルがパッケージとしてはインストールされないので、 注意してください。これは sarge では変更され、 カーネルの変更を追いかけるために仮想パッケージをインストールできるようになりました。 これらのパッケージは kernel-image-VERSION-ARCH という名前になっていて、 VERSION の部分は対応するカーネルのバージョン番号 (2.4 や 2.6) に、 ARCH の部分はサポートされるアーキテクチャのいずれかに対応しています。 カーネルに対するセキュリティサポートもパッケージ管理に統合したいなら、 アップグレードした後で、お使いのハードウェアに最適なカーネルパッケージをインストールしてください。

もうちょっと冒険したい人には、 自分のカスタムカーネルをコンパイルする方法も Debian GNU/Linux は提供しています。 kernel-package をインストールして、 /usr/share/doc/kernel-package の文書を読んでみてください。


4.5.2 raidtools2 から mdadm へのアップグレード

raidtools2 はもはや上流開発者によって保守されておらず、 mdadm パッケージに置き換えられました。 mdadm は、設定ファイルなしにほぼ全ての RAID 管理タスクを実行できる 単一のプログラムです - 設定ファイルはデフォルトでは使いません。

このセクションの以降の部分では、raidtools2 のユーザにアップグレード のヒントをいくつか提供します。

上述したように、多くの場合 mdadm は設定ファイルなしで動作可能です。 専用の RAID アレイを自動的に設定してくれるカーネルを使っているのなら、この 節は飛ばしてもかまいません — mdadmをインストールするだけで、 RAID は起動プロセス中に検出されるでしょう。Debian の標準的なカーネルは、 起動時の RAID アレイ設定に対応しています。パーティションが "Linux raid autodetect" (id fd) に設定されていることを確認する必要もあるでしょう。 以下のコマンドを実行すれば、現在のパーティションの種類が一覧表示されます:

     # fdisk -l disk_device

自動的に設定された RAID アレイとそうではないものが混在した設定となって いるなら、設定ファイルを作成しなければなりません。

/etc/raidtab(raidtools2) から /etc/mdadm/mdadm.conf (mdadm) へ移行するには、以下のように実行してください:

     # echo 'DEVICE /dev/hd*[0-9] /dev/sd*[0-9]' > /etc/mdadm/mdadm.conf
     # mdadm --examine --scan >> /etc/mdadm/mdadm.conf

これらのコマンドは、システムの既存のアレイに関する設定ファイルを生成 します。

起動時に、RAID アレイが自動的に開始されることも確認すべきです。変数 AUTOSTART が true となっているかを確認するには、/etc/default/mdadm ファイルを調べてください。


4.6 時代遅れ (Obsolete) なパッケージ

数千個の新規パッケージが導入された一方で、sarge では woody にはあった 2000 個以上の古いパッケージが破棄され たり削除されてもいます。これら時代遅れのパッケージをアップグレード する手段は提供されていません。時代遅れのパッケージを使い続けても 構いませんが、Debian プロジェクトは通常 sarge がリリース されてから 1 年後に[3]そのようなパッケージへのセキュリティサポー トを打ち切り、その後は他のサポートも提供されないのが常です。もし存 在するのなら、利用可能な代替品に置き換えることを推奨します。

あるパッケージが本ディストリビューションから削除された理由は、数 多くあります - 上流ではもはや保守されていないため、そのパッケージを 保守することに興味を抱く Debian 開発者がもはやいないため、提供してい た機能が別のソフトウェア (あるいは新バージョン) に取って代わられたた め、バグのために sarge にはもはや適さないとみなされたため、 などです。最後の場合では、当該パッケージが "不安定版" ディストリビュー ション内には存在していることがあります。

更新されたシステム内のどのパッケージが "時代遅れ" なのかを 検出するのは、パッケージ管理用フロントエンドが当該パッケージに その旨のマークを付けてくれるので簡単です。aptitude を 使っているのなら、当該パッケージが "Obsolete and Locally Created Packages" 欄に列記されているのに気づくでしょう。 dselect も同じようなセクションを提供しますが、表示 される一覧はわずかに異なっています。さらに、woody で 手作業でパッケージをインストールするのに aptitude を 使っていたのなら、手作業でインストールされたパッケージの記録が取ら れており、依存元パッケージが削除されればもはや不要となる依存関係の みによって導入されたパッケージに時代遅れのマークを付けることができ るでしょう。また aptitude は、deborphan と は異なり、手作業でインストールしたパッケージには時代遅れのマークを 付けません (依存関係によって自動でインストールされたものにはマークを 付けます)。

時代遅れのパッケージを見つけるのに使える追加ツールとしては、以下 のものがあります - deborphandebfostercruftdeborphan を強く推奨しますが、同プロ グラムは (デフォルトモードでは) 時代遅れのライブラリ - "libs" や "oldlibs" セクション内にあり、他のパッケージに使われていないパッケー ジ - しか報告しません。これらのプログラムが表示したパッケージをやみく もに削除しないでください。特に、誤報しやすい非デフォルトのオプションを 積極的に使っている場合はなおさらです。実際に削除する前に、削除を提案さ れたパッケージを手作業で調査 (その中身やサイズ、説明文など) することを 強く推奨します。

Debian バグ追跡システム は、パッケージ が削除された理由についての情報を提供してくれることがよくあります。 あるパッケージ自体についてのアーカイブ化されたバグ報告と、ftp.debian.org pseudo-package のアーカイブ化されたバグ報告の 両方を調査すべきです。


4.6.1 ダミーパッケージ

woody のいくつかのパッケージは sarge では複数の パッケージに分割されていますが、これは大半がシステムの保守性を改善す るためです。この場合におけるアップグレードを容易にするために、 sarge はしばしば "ダミーの" パッケージ - woody での 古いパッケージと同じ名前で、新規パッケージを導入するための依存関係を 備えた空のパッケージ -を提供しています。これらの "ダミー" パッケージ はアップグレード後は Obsolete 扱いとされ、安全に削除することができます。

大半の (すべてではない) ダミーパッケージの説明文には、その目的が 記されています。しかしながらダミーパッケージの説明文は統一されていな いため、自分のシステム内のダミーパッケージを検出するために deborphan--guess オプション付で使うことも できます。いくつかのダミーパッケージは、アップグレード後に削除される ことを意図しておらず、代わりに時間とともに変化するプログラムの利用可 能な最新バージョンの記録用として使われることに注意してください。


[ 前のページ ] [ 目次 ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ A ] [ 次のページ ]


Debian GNU/Linux 3.1 (`sarge') リリースノート (IA-64 用)

$Id: release-notes.ja.sgml,v 1.13 2006/04/17 11:56:08 jseidel Exp $

Josip Rodin, Bob Hilliard, Adam Di Carlo, Anne Bezemer, Rob Bradford (現在のメンテナ), Frans Pop (現在のメンテナ)
debian-doc@lists.debian.org