apt-getからaptitudeに切り替える際に問題が発生する可能性はありますか？
私はaptitudeへの切り替えを考えていましたが、「すでにapt-getを使用している場合は、次のインストールが切り替わるまで待つ必要があります」と言われることがあります。なぜ人々はこれを言うのですか？これはどのような問題（もしあれば）を引き起こす可能性がありますか？
apt-getとaptitudeは、同じパッケージ管理システムの一部である異なるUIです APT、Advanced Packaging Tool 。たとえば、どちらも/etc/apt/apt.confを使用して構成され、パッケージの状態を表すために同じファイルスペースと形式を使用し、ダウンロードされた.debsを格納するために同じファイルスペースを使用します。
それらの違いは、パッケージ間の潜在的な競合を表す内部ルールシステム、それらを解決する方法（たとえば、apt-get dist-upgradeとaptitude full-upgradeの間）、およびユーザーと対話するときにこれらを表現する方法です。一般的に言って、どちらもトリッキーな状況では間違ったことをするかもしれませんが、apt-getは適性よりも間違っている可能性がはるかに高いです。
すでにたくさんの良いアドバイスがここにありますが、誰も言及していないことを1つ付け加えておきます。 もし切り替えることにした場合は、apt-getで何をしてきたかに応じて、このコマンドを実行することをお勧めします。
aptitude keep-all
このコマンドは、どのパッケージが孤立していて削除する必要があるかについてのaptitudeの感覚をリセットします。
これが時々役立つ理由です：しばらくの間、apt-getとaptitudeの両方が、他の何かの依存関係として自動的にインストールされたパッケージを追跡します。したがって、たとえば、mpdをインストールすると、依存関係としてlib-so-and-soを取得する可能性があります。これを行うため、後でmpdを削除すると、lib-so-and-soも削除されます。ただし、aptitudeとapt-getはこのクリーンアップを異なる方法で処理します。 aptitudeは、孤立した依存関係をすべてすぐに削除しようとします。ただし、apt-getは、クリーンアップするためにapt-get autoremoveを実行することを提案するだけです。 （このすべての背後にある論理は、mpdが必要としたため、ライブラリのみを取得したということです。mpdを保持しない場合、ライブラリはもう必要ありません。 anotherパッケージはまだそれに依存しているので、aptitudeとapt-getの両方がこれを認識し、ライブラリを削除しようとはしません。）
私のポイントは何ですか？さて、apt-get autoremoveを実行するための絶え間ない微調整を見ていて、aptitudeに切り替えると、初めて何かをインストールしようとしたときにショックを受ける可能性があります。 aptitudeは、すぐにそれらすべての孤児を削除しようとします。一般に、これは問題ありません（結局、孤児であり、必要ではありません）が、複雑なケースが1つあります。デスクトップメタパッケージはすべて、仮想パッケージラッパーの依存関係として個々のプログラムが引き込まれる複雑な依存関係チェーンを含みます。たとえば、gnomeパッケージをインストールしたためにGnomeがインストールされている場合、通常のデスクトッププログラムはすべて依存関係としてインストールされています。これらのプログラムの1つ（EkigaやGeditなど）をアンインストールした場合は、aptitudeの目から見てデスクトップの残りの部分も削除する必要があります。 aptitude常には物事を削除する前に尋ねますが、人々はしばしば「Y」を読まずに入力することに注意してください。私の経験では、これはDebianを初めて使用する人々にとって最も一般的な苦情/混乱です。
2つの一般的なアドバイス：
- 常に
aptitudeまたはapt-getの出力を注意深く読んでから、何かに「はい」と言ってください。 aptitude -s safe-upgradeまたはaptitude -s install fooを使用していつでもドライランを実行できることを忘れないでください。-s|--simulateフラグはあなたの友達です。
数年前、Debianメーリングリストで、apt-getからaptitudeに切り替えるのは危険だと言われていました。これは2つのDebianバージョン（たとえば10年）前です。これらの問題はすべて解決されたようですが、DebianでもUbuntuでも問題は発生していません。
また、先に進んでaptitudeを使用すると思います。Aptitudeは、apt-getよりも優れた依存関係管理を備えています。これにより、孤立したパッケージの数を少なく抑えることができます。
少し前に、aptitudeの方がapt-getよりも優れたdistアップグレードアルゴリズムを使用していることを読みました。しかし、それはシステムの存続期間中にそれほど頻繁に使用されないため、キラー機能とは言えません。
さらに、1つのツールに統合されたものが増えます。いつapt-get、apt-cache、またはdpkgを呼び出すか、どのスイッチを使用するかを覚えているのではなく、aptitudeを使用してほとんどのことを実行します。
「途中」で切り替えるときの合併症について：私がそれをしたときに何かあったことを覚えていません。
それらは同じバックエンドへの単なる異なるインターフェースではありませんか？
私の経験から、パッケージバージョンを固定する方法は異なります。私の場合、将来の更新から安全であると仮定して、特定のパッケージをロックするように適性に伝えました。私は間違っていた; apt-getを使用するcronでスケジュールされた更新マネージャーは、私の失望にアップグレードします。
Drats、これを書いているときにグーグルで調べたところ、バグ（ ＃55758 aptitudeはpreferences.d/*のピンに従わない）はすでに修正されていることがわかりました。