優れたソフトウェアと実用的なチュートリアル
まずRPMパッケージを理解しましょう
RPM はパッケージ形式であり、低レベルのパッケージマネージャーです。低レベルパッケージマネージャーは基本的な機能を備えており、パッケージのインストールは自動的に行われますが、インストールを指定したパッケージは、その依存関係がすべてインストールされている場合にのみアンインストールされます。依存関係やリポジトリの管理は行いません。RPM は、Debian の dpkg や Slackware の pkgtools などの他の低レベルパッケージマネージャーと同様に、リポジトリの存在を必要としません。そのため、RPM を使用してパッケージをインストールしようとした際に依存関係が不足している場合、自動的に解決されず、手動でダウンロードしてインストールする必要があります。RPM の依存関係パッケージを自分で検索し、RPM のダウンロード URL を指定する必要があります。
DNFが初登場
Fedoraのファンでバージョン22にアップグレードした方は、大きな変更に気づいたかもしれません。おなじみの（そして長年の）おいしいパッケージマネージャーは廃止されました。その代わりに、より強力でスマートなDandified Yum (DNF) が登場しました。
yum に代わる DNF パッケージマネージャーを導入したのはなぜでしょうか？また、新しいパッケージ管理システムの使い方についても教えてください。
始める前に、コマンドラインを全く使わない人（Fedoraシステムではおそらく稀でしょう）であれば、特に異常は見られないはずです。GUIフロントエンドは（ほぼ）同じままで、デスクトップも同じです。ただし、コマンドラインからソフトウェアをインストールするのが好きな方は、コマンド実行時に新しいテキストが一瞬表示されることに気付くでしょう。
yumが廃止された理由
YumがDNFにアップグレードされた主な理由は3つあります。これらの理由は古く、深刻なため、Yumは放棄せざるを得ませんでした。
ドキュメント化されていないAPI - これは開発者の作業負担を増大させました。開発者が必要な作業を行うには、Yumのコードベースを参照して呼び出しを記述する必要がありました。そのため、開発は非常に遅くなりました。
Python 3 – Fedora は Python 3 に移行しており、Yum はこの変更に耐えられませんが、DNF は Python 2 または Python 3 のいずれかで実行できます。
壊れた依存関係解決アルゴリズム - これは長年、Fedora パッケージマネージャの弱点でした。DNF は最先端の充足可能性 (SAT) に基づく依存関係解決を採用しています。これは、SUSE および openSUSE の Zypper で使用されているものと同じタイプの依存関係解決ツールです。
簡単に言えば、Yum は時代遅れであり、最新の Fedora ディストリビューションの厳しさに耐えることができません。
DNF の利点は何ですか?
これをエンドユーザーと開発者という2つの異なる視点から見る必要があります。エンドユーザーにとって、YumからDNFへの切り替えは、非常にシンプルなメリットをもたらします。それは、より信頼性の高いエクスペリエンスです。この信頼性の源は、DNFの優れた依存関係解決機能です。パッケージのインストール時にシステムが依存関係を解決できないことは、今では非常に稀です。システムがより賢くなったのです。Yumの依存関係アルゴリズムはそもそも破綻していました。DNFのSATベースの依存関係解決機能は、この問題を解決します。
エンドユーザーは、パッケージのインストール時にメモリ使用量が削減されることを実感できるでしょう。インストールとアップグレードも高速化されます。最後の点は特に重要です。Yumツールを使ったアップグレードは、（特にapt-getやzypperなどのツールと比べると）許容できないほど遅くなり始めます。
開発者にとって、DNFへの移行は、より効率的かつ信頼性の高い作業を可能にします。公開されているすべてのAPIはドキュメント化されています。開発者にとってもう一つのメリットは、C言語が実装されることです。開発者たちは既にhawkeyeとlibrepo（ソフトウェアリポジトリからパッケージとメタデータをダウンロードするためのCおよびPythonライブラリ）を作成しており、今後さらに多くのCベースのAPIをリリースする予定です。C言語は依然として広く使用されている言語であり（現在TIOBEインデックスで2位）、これは開発者にとって歓迎すべき変化となるはずです。
dnf コマンドの使い方は？
ここでエンドユーザーにとって朗報です。YumからDNFへの移行は、記憶力の試練となるでしょう。ターミナルウィンドウを開いてコマンドラインインストールを実行する際、yum install phpというコマンドを実行することが多いでしょう。しかし、今後はそうではありません。DNF化されたコマンドは、dnf install phpになります。
yumからdnfへの切り替え
道のりにはいくつかの障害があるでしょう。そうです、DNF は Yum の代替です。Yum の上級ユーザーでなければ、移行中に問題に遭遇することはおそらくないでしょう。しかし、まだ発見されていない問題がいくつかあります。古い yum update --skip-broken コマンドを調べてみましょう。このコマンドを使用すると、更新は実行されますが、壊れた依存関係を持つすべてのパッケージがスキップされます。一方、DNF はデフォルトでこれらの壊れたパッケージをスキップします。これを実現するために「skip broken」フラグを含める必要はありません。壊れたパッケージを報告させるために DNF が必要な場合は、DNF update を実行してから DNF check-update を実行する必要があります。以前は簡単だったプロセスに余分な手順が追加されるため、一部のユーザーはこの動作を好みません。上級ユーザーにとっては、DNF は Yum よりも手間がかかる可能性があります。一方、標準ユーザーにとっては、DNF は yum コマンドを DNF コマンドに置き換えただけです。
YumからDNFへの移行は、特に何も知らないユーザーがコマンドラインを開いてyumを使おうとすると、しばらくの間は少し面倒です。しかし、その場合でも警告が表示されます。
Yum コマンドは非推奨になりました。代わりに dnf を使用してください。
詳細については、「man dnf」および「man yum2dnf」を参照してください。
トランザクションメタデータをyumからDNFに転送するには、「dnf migrate」を実行します。
中国語に翻訳すると、おそらくyumコマンドは廃止されたので、dnfを使用してくださいという意味です。
明らかに何かが変わったようです。しかし、開発者は「man dnf」とだけ言うのではなく、もっと明確な警告を出すべきだったと思います。代わりに、次のような表現が適切だったでしょう。
yumコマンドは使用されなくなりました。新しいシステムを使用するには、コマンド内の「yum」を「dnf」に置き換えてください。
このようなプロンプトが表示された場合、すべてのターミナル ユーザーが知っておく必要があるのは、「yum」を「dnf」に置き換えることだけです。
yumとDNFは、基本的に依存関係とソフトウェアリポジトリを管理し、RPMを利用してパッケージのインストール、ダウンロード、削除を行うプログラムです。DNFはyumの後継であり、yumとの主な違いは、openSUSEのZYppパッケージマネージャーのライブラリをいくつか使用することで、速度向上やその他の側面の改善を図っていることです（ただし、私が実施したインストール速度テストでは、DNFは実際にはyumに対して大きな優位性がないことが示されました）。
