ファイル拡張子として使われます。パッケージは同一のパッケージ構造を共有しています。マイクロと言う意味で使っています。パッケージ管理の最も低レベルのツールです。非常に強力ですから気をつけて使う必要があります。次に記す順番でパッケージを処理します。サポートのある標準化されたユーザーとの対話が実現できます。設定ファイルのリスト。ようなツールによって使われます。メタデーターのローカルコピーを検索できます。パッケージを開けるのに用いられます。用いて何らかの重畳するプログラムを平和裏にインストールするメカニズムがあります。選択して実行するようにできます。中のシムリンクとして保持します。中の対応するファイルが使われます。指定されファイルが存在すれば、即座に新たな所有者やモードに設定されます。コマンドを用いて直接変更しても次のパッケージアップグレードがリセットします。扱うディレクトリーやデバイス等のいかなるファイルシステムオブジェクトであってもいいです。本来パッケージメインテナンススクリプトのためのものです。システム管理者がこれを軽々に使うのはお薦めできません。システムを動かす時には、管理者には壊れたパッケージ管理状況から復元できることが望まれます。注意ここで説明するいくつかの方法は非常にリスクが高いアクションです。プログラムが上流の大きなバージョンアップグレードの後に不安定性を経験した際には、そのプログラムが作った古いローカル設定ファイルとの干渉を疑うべきです。新規作成したユーザーアカウントでそのプログラムが安定なら、この仮説が裏付けられます。(これはパッケージングのバグで、通常パッケージャーによって回避されます。プログラムを再スタートします。後日設定情報を回復するために古い設定ファイルの内容を読む必要があるかもしれません。(あまり慌てて消去しないようにしましょう。(「パッケージ依存関係」参照下さい)。あった場合には、パッケージ依存関係が誤って定義される事態が発生するかもしれません。既存ファイルを上書きすることなく呼ばれたプログラムにエラーを確実に返します。権限で実行されるシステムに関して何でもできるメンテナスクリプトが実行されるので、システムが重大なリスクにさらされます。パッケージを展開するするさいに上書きする事を防止するだけです。削除すれば回避できます。壊れたパッケージスクリプトの修正パッケージスクリプト内のコマンドが何らかの理由でエラーを返しスクリプトがエラーで終了した場合には、パッケージ管理システムは動作を途中終了するので部分的にインストールされたパッケージのある状況が生まれます。パッケージがその削除スクリプト内にバグを持つ場合には、パッケージが削除不能になりうるので大変厄介です。パッケージスクリプトの問題に関しては、次のパッケージスクリプトの内容を確認するべきです。挿入し成功を強制的に返さす全ての部分的にインストールされたパッケージを次のコマンドで設定します。非常に低レベルのパッケージツールなのでネットワーク接続もないブート不能な非常に劣悪な状況下でも機能します。パッケージが壊れていて置き換える必要があると仮定します。あるパッケージキャッシュの中に見つかるかもしれません。アーカイブからダウンロードしたり、機能している機器のパッケージキャッシュからコピーできます。)もしブート不可能な場合には、次のコマンドを使ってインストールすることもできます。システムを通じてシステム全体をダウングレードする手もあります。ハードディスクからブートできない場合は、他の方法でのブート方法を考えるべきです。使ってレスキューモードでブートします。パッケージを次のようにしてインストールします。コマンドが壊れていても機能します。システムでも同様にして壊れたシステムを救済するのに使えます。他のオプションを使って依存関係をオーバーライドすることができます。した場合には、後で適正な依存関係を修復するように真剣に取り組む必要があります。(「バックアップと復元」参照下さい)、クリーンインストールを実行するべきです。することは時間の節約でもあり最終的に良い結果に結びつきます。システムはパッケージ選択データーが失われ大きな打撃を被ります。してあるので探します。多くの重要な情報を保持しているので、これを別のパーティション上に置くのも良い考えです。ひどく壊れた場合には、システムのバックアップをした後フレッシュに再インストールすることをお薦めします。ディレクトリー中から新規インストールのガイドとなる情報を復元できます。システムを再インストールします。古いシステムをマウントします。lessこうすると、インストールすべきパッケージ名が表示されます。ようなパッケージ名以外が一部あるかもしれません。見つけることができます。努力無しにどのパッケージをインストールするか迷った際には、常識を使って下さい。次に示す点は好ましいパッケージの良い指標と考えます。分散型の開発モデルのボランティアプロジェクトですので、そのアーカイブには目指すところや品質の異なる多くのパッケージがあります。これらをどうするかは自己判断をして下さい。ディストリビューションとしてサポートしていません。ある特定の新規アップストリームバージョンのパッケージを1回だけ取り入れる操作例を次に示します。エントリーのみにします。<パッケージ名>"の実行します。ファイルを復元します。ついて悩むこともありません。これではとても面倒です。保証していないので、その場合にはパッケージ間の互換性は自分自身で確保しなければいけません。パッケージに互換性がないと、システムを壊すことになるかもしれません。この様な技術的要件を判断できる必要があります。ランダムな混合したアーカイブソースを使うことは全く任意の操作ですが、私としてはこの操作はお薦めできません。異なるアーカイブからパッケージをインストールするための一般ルールは以下です。非バイナリーパッケージのインストールは比較的安全です。インストールは、通常多くの障害があり、安全ではありません。バイナリープログラムパッケージは完全に静的にリンクされたライブラリーとともに提供される事があります。互換性等の問題は確認するべきです。壊れたパッケージを短期的に避ける場合以外では、公式にサポートされていないアーカイブからバイナリーパッケージをインストールするのは一般的には賢明ではありません。使った場合にもこれは当てはまります。使って、他のアーカイブからのプログラムを実行するよう検討するべきです。システムはバージョン文字列を用いて、最新利用可能バージョンを候補バージョンとします。システムの最も推薦される使い方です。ファイルを必要としません。ファイルを作り候補バージョンに関するパッケージ選択ルールを操作することによってこういった複雑な操作を自動化できます。利用は大トラブル発生を間違いなく起こします。利用は避けなければいけません。パッケージの互換性を保証しないので、ユーザー自身がパッケージの互換性を確保しなければいけません。任意の操作で、著者が使うようにと勧めているわけではありません。名を使って機能します。アーカイブとは異なります)。一部に使う場合には、それが提供されている対象の確認とその信頼性の確認をします。混合して使うようにはなっていません。テクニックの説明を次にします。アップグレードするパッケージを候補バージョンパッケージとして選択します。(「緊急ダウングレード」参照下さい)。項目にて規定されるか、そのデフォールト値が使われます。されても、パッケージを絶対にインストールしないターゲットのリリースアーカイブは次のようにして設定できます。アーカイブと設定されます。パッケージバージョンを示します。等としてリストされます。等としてリストされます。等としてリストされます。アーカイブがあります。ファイル中に全ての必要なアーカイブをリストします。値を明示的に設定する必要はありません。新しいパッケージにアップグレードされます。新しいパッケージにアップグレードされます。オプションでターゲットリリースを切り替えながら次のコマンドを使います。ファイルを作成しその中に全てのパッケージを次のように明示的にリストしなければいけません。テクニックの例を次に示します。ファイル中に次のようにリストします。次のように設定します。次のコマンドを実行します。アーカイブを使ってアップグレードします。項目を削除しないように注意します。アーカイブを使ってアップグレードします。アーカイブ項目をコメントアウトします。ファイル中に項目が多すぎてアップデートのプロセスが遅くなることをさけられます。アーカイブによってアップグレードされる事はありません。ファイルを作りそのトップにこれらパッケージを明示的に次のようにリストします。ファイルに次の項目を設定します。アーカイブを追跡している際にも有効です。アーカイブからインストールしても今までいつも安全でした。テクニックの例を示します。ファイルに次のようにリストします。値を明示的に設定する必要はありません。パッケージをインストールすることで自動アップグレード実行の機能拡張をします。中のパラメーターでカスタム化できます。システムのセキュリティーアップグレードのためです。システムが、自動アップグレードで壊される危険性が、セキュリティーアップグレードがすでに閉じたセキュリティーホールからの侵入者によりシステムが壊わされる危険性より小さいなら、パラメーターを次のように設定して自動アップグレードをするのも一計です。システムを使っている場合には、自動アップグレードするとシステムはいつの日か確実に壊われるので、それはしたくないでしょう。場合でも、次に記すような事前にパッケージをダウンロードするパラメーターを設定でインタラクティブなアップグレードをするための時間を節約したいでしょう。パラメーターを次のように設定します。設計としてはダウングレードを正式にサポートしません。緊急の復元処置の一部としてのみ実行されるべきです。いう状況であるにもかかわらず、多くの場合にうまく機能することが知られています。重要なシステムでは回復処置の後に全ての重要データーをバックアップし、最初から新規システムを再インストールします。(「候補バージョンの調整」参照下さい)。コマンドを使っての救済」参照下さい)。ファイル中の行を探します。追いかけるように次と交換します。次のように設定します。実行して、システム全体にわたってパッケージのダウングレードを強制します。ファイルを削除します。システムのダウングレードのためには手動でいくつかのパッケージを削除とインストールしなければいけないかも知れません。ネットワーク関係のパッケージやそれらの設定ファイルには特に注意が必要です。関していくばくかの情報を提供しますが、パッケージを実際にアップロードをした人がはっきりしません。ソースパッケージを実際にアップロードした人を確定します。私的アーカイブを使うのが好ましいです。使う必要があるかもしれません。システムの部分アップグレードのためには、その環境内でソースパッケージを使ってパッケージをリビルドするのが好ましいです。することでパッケージ依存関係による大掛かりなアップグレードをしないで済みます。ファイルに次のエントリーを追加します。non-freeコンパイルするのに必要なパッケージをインストールしソースパッケージをダウンロードをします。等のツールチェインパッケージをバックポートパッケージを用いてアップデートします。中でパッケージバージョンを先に進める次のようにしてパッケージをビルドしシステムにインストールします。ためのローカルのプロキシサーバーを設置することを考えるのは良いことです。使うように設定できます。ファイル中の設定より優先します。アーカイブ専用のプロキシツールがあります。そのアーカイブ構造を再編した際に、このような専用のプロキシツールはパッケージメンテナによるコードの修正が必要で、一定期間使えなくなることがあります。プロキシは比較的堅牢ですしそのような変化に合わすのも簡単です。小さな公開パッケージアーカイブヒント手動でパッケージアーカイブを設定するのは複雑です。いくつかのレポジトリー管理ツールが有ります。オンラインであります。互換性のある小規模のパブリックアーカイブを作る例を次に示します。いくつかの仮定をします。アーカイブキーを作成します。いうアーカイブツリーを作成します。設定することで自動化できます。フックスクリプトがアップロード毎に更新されたアーカイブファイルを作成します。