dnf-makecache.timerが必要なのはなぜですか？

Question 1

いいですね。しかし、これは実際に何を意味しますか？

これは、後続のコマンドを高速化するために、パッケージのリモートインデックスがローカルファイルキャッシュにダウンロードされることを意味しますdnf。

ストレージキャッシュを毎時間更新する必要があるのはなぜですか？

dnfこれはコマンドを促進し、スピードを上げるために行われます。 egコマンドを実行するたびに、dnf install「新しい」リポジトリメタデータが必要です。それ以外の場合は、インタラクティブにコマンドを実行するときにメタデータが更新されるのを待つ必要がありますdnf。

タイマーは1時間ごとに設定されていますが、実際には3時間を超えて実行されません。これはバグです。詳細は次のとおりです。ここ。

dnf updateを使って手動で更新すると、これは起こりませんか？

はい、とにかくデフォルトで発生します。メタデータが古いと見なされる場合。つまり、デフォルトの寿命である6時間を超えました（ストレージ定義ごとにこのTTLをオーバーライドできます）。 repoがこのように定義されている場合、これは発生しませんmetadata_expire=-1。

dnf-makecache を更新しないと、dnf の更新が失敗するか、最新バージョンを取得できませんか?

いいえ、失敗しません。メタデータがすでに存在し、ネットワーク接続が不安定である場合は、少し安定している可能性があると主張することもできます。

それとも、自動を使用しない場合は、不要なdnf-automaticに追加されますか？

どちらも新しいメタデータキャッシュを使用して実行される可能性が高く、高速に実行されるため、両方dnfを補完します。dnf-automatic

systemctlを無効にするdnf-makecache.timerとsystemctl stop dnf-makecache.timerを使用してこのタイマーを無効にする場合の欠点/欠点は何ですか？

dnfインストールとアップデートを待つ速度が遅いコマンド/対話型です。記事のフォローアップを行い、調整しない限り：

metadata_timer_sync=3600

タイマーは非常に非効率的で、あまり良い仕事をしません。

PS、質問をたくさんしますが、このコミュニティでは一般的に一つの質問をしなければなりません。 :)

man dnfと相談してみてくださいman dnf.conf。正しく文書化する人々の努力は無駄にならないでください。

Answer

いいですね。しかし、これは実際に何を意味しますか？