Red Hat のダニエル・マッハ DNF 5 パッケージ マネージャーの開発の開始について説明します。このマネージャーでは、Python で実装された DNF ロジックが C++ で書かれた libdnf ライブラリに転送されます。 DNF 5は、Fedora 33の開発中の2020月にテストを開始する予定で、その後、2021年4月にRawhideリポジトリに追加され、4年8月にDNF XNUMXに置き換わる予定です。DNF XNUMXブランチのメンテナンスはそのまま継続されます。 Red Hat Enterprise Linux XNUMX で使用されます。
プロジェクトは、API/ABI レベルでの互換性を損なうことなくコードの開発を続行することがほぼ不可能な状態に達していることに注意してください。 これは主に次の理由によるものです PackageKit の関連性と、「libhif」API を変更せずに libdnf を開発するのは不可能です。 同時に、API を変更する意図があるにもかかわらず、コマンド ライン インターフェイスと API のレベルでの下位互換性を維持することが主な優先事項であると言われています。
DNF での Python API のサポートは維持されますが、Python で記述されたビジネス ロジックは libdnf (C++) ライブラリに転送され、ディストリビューション内のパッケージ マネージャーの同一の動作が保証されます。 開発はC++ APIを中心に行われ、Python APIはそれをベースにしたラッパー形式で自動生成されます。
Go、Perl、および
ルビー。 C++ API が安定した後、それをベースに C API が作成され、そこに rpm-ostree が転送されます。 Python API は削除され、次のように置き換えられます。 Python API。
DNF のコア機能は保持されます。 大規模なテスト スイート (約 1400 のテスト) のため、API の再作業はエンド ユーザーのコマンド ライン インターフェイスに影響を与えないと予想されます。 引数の解析と出力は若干変更される可能性がありますが、これらの変更は十分に文書化されます。 機能を簡素化したバージョンで 、コンテナーで使用される場合、DNF 機能のサブセットを実装することが計画されており、機能の完全な同等性の達成は考慮されていません。
代わりに グラフィカル アプリケーションのパッケージと更新を管理するためのインターフェイスを提供する新しい DBus サービスが作成されます。 このサービスはゼロから開発する予定のため、作成には多大な時間を要する可能性があります。 PackageKit は最近開発されておらず、関連性が失われたため 2014 年からメンテナンス モードになっています。 Snap および Flatpak システムの進歩により、ディストリビューションは PackageKit への関心を失いつつあります。たとえば、パッケージキットはビルドで利用できなくなりました。 。 パッケージ管理の抽象化レイヤーは、主にネイティブの GNOME および KDE アプリケーション コントロール センターによって提供され、個々のユーザー レベルで flatpak パッケージをインストールできます。 インストールされているパッケージのリストを取得するための統合システム API は、以前ほど便利ではありません。
出所： オープンネット.ru