dnf update でアップデートしても dnf-automatic では更新があると言われる

AlmaLinux OS 10 で dnf update でパッケージを更新したのに、dnf-automatic から以下のような通知が来る。

================================================================================
 Package                     Arch        Version                Repo       Size
================================================================================
Upgrading:
 certbot                     noarch      4.2.0-1.el10_2         epel       51 k
 python-josepy-doc           noarch      2.0.0-2.el10_1         epel       10 k
 python3-acme                noarch      4.2.0-1.el10_2         epel      210 k
 python3-certbot             noarch      4.2.0-1.el10_2         epel      881 k
 python3-configargparse      noarch      1.7.1-1.el10_1         epel       53 k
 python3-josepy              noarch      2.0.0-2.el10_1         epel       72 k
 python3-pyOpenSSL           noarch      25.0.0-1.el10_1        epel      113 k
 python3-pytz                noarch      2025.1-1.el10_1        epel       56 k

毎日メールが来るし、なぜこうなるか分からないのは大変気持ちが悪い。というわけで調べてみた。

問題の追跡

certbot のバージョン

インストールされている（dnf で update されている）certbot のバージョン

# rpm -q certbot
certbot-4.2.0-1.el10_0.noarch

dnf-automatic で通知される certbot のバージョン

certbot                     noarch      4.2.0-1.el10_2 

なんでバージョンが違っているのか。わけがわからない。

epel リポジトリの環境

epel リポジトリをインストールしている

 /etc/yum.repos.d/epel.repo
[epel]
name=Extra Packages for Enterprise Linux $releasever - $basearch
# It is much more secure to use the metalink, but if you wish to use a local mirror
# place its address here.
#baseurl=https://download.example/pub/epel/$releasever${releasever_minor:+z}/Everything/$basearch/
metalink=https://mirrors.fedoraproject.org/metalink?repo=epel${releasever_minor:+-z}-$releasever&arch=$basearch
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-$releasever_major
gpgcheck=1
repo_gpgcheck=0
metadata_expire=24h
countme=1
enabled=1

epel リポジトリは有効になっている

# sudo dnf repolist -v epel
Loaded plugins: builddep, changelog, config-manager, copr, debuginfo-install, download, generate_completion_cache, groups-manager, needs-restarting, playground, repoclosure, repodiff, repograph, repomanage, reposync, system-upgrade
DNF version: 4.20.0
cachedir: /var/cache/dnf
Last metadata expiration check: 0:28:40 ago on Sun 21 Sep 2025 09:15:17 AM JST.
Repo-id            : epel
Repo-name          : Extra Packages for Enterprise Linux 10 - x86_64
Repo-status        : enabled
Repo-revision      : 1758331800
Repo-updated       : Sat 20 Sep 2025 10:30:15 AM JST
Repo-pkgs          : 17,870
Repo-available-pkgs: 17,870
Repo-size          : 16 G
Repo-metalink      : https://mirrors.fedoraproject.org/metalink?repo=epel-z-10&arch=x86_64
  Updated          : Sun 21 Sep 2025 09:15:12 AM JST
Repo-baseurl       : http://ftp.riken.jp/Linux/fedora/epel/10.0/Everything/x86_64/ (72 more)
Repo-expire        : 86,400 second(s) (last: Sun 21 Sep 2025 09:15:12 AM JST)
Repo-filename      : /etc/yum.repos.d/epel.repo
Total packages: 17,870 

ファイル名から rpm がどこにあるか探してみる

certbot-4.2.0-1.el10_2.noarch.rpm を調べると、epel の 10（現時点）または 10.2 にある。

https://ftp.iij.ad.jp/pub/linux/Fedora/epel/10/Everything/x86_64/Packages/c/
https://ftp.iij.ad.jp/pub/linux/Fedora/epel/10.2/Everything/x86_64/Packages/c/

一方 certbot-4.2.0-1.el10_0.noarch.rpm は epel の 10.0 にある。

https://ftp.iij.ad.jp/pub/linux/Fedora/epel/10.0/Everything/x86_64/Packages/c/

ということは、dnf と dnf-automatic で、参照しているリポジトリが異なってしまっているようだ。

なぜリポジトリが異なるのか

dnf repolist で見ると、metalink の https://mirrors.fedoraproject.org/metalink?repo=epel${releasever_minor:+-z}-$releasever&arch=$basearch は https://mirrors.fedoraproject.org/metalink?repo=epel-z-10&arch=x86_64 に展開される。
取得したメタデータファイル中の URL は /epel/10.0/ になっている。

dnf-automatic を実行したときの様子を /var/log/dnf.librepo.log で見ると、https://mirrors.fedoraproject.org/metalink?repo=epel-10&arch=x86_64 にアクセスしている。つまり epel-z-10 が epel-10 に書き換わっている。
ここから取得したメタデータファイル中の URL は /epel/10.2/ になっている。

なぜ metalink が書き換わるのか

ここから先は dnf-automatic を起点に、その奥を print デバッグするしかなかった。
/usr/lib/python3.12/site-packages/dnf/cli/cli.py の _read_conf_file() を呼び出すと、epel-z-10 が epel-10 に書き換わってしまうことが分かった。

dnf のリポジトリを調べて dnf/cli/cli.py を見ると、b7eb2e3 という修正が入っていた。この問題は issue #2259 として報告されていた。

というわけで、既知のバグで修正が入っているが、まだ修正は baseos には適用されていないということのようだ。

問題の回避方法

/etc/yum.repos.d/epel.repo を修正する。

 #baseurl=https://download.example/pub/epel/$releasever${releasever_minor:+z}/Everything/$basearch/
+baseurl=https://ftp.iij.ad.jp/pub/linux/Fedora/epel/10.0/Everything/x86_64/
-metalink=https://mirrors.fedoraproject.org/metalink?repo=epel${releasever_minor:+-z}-$releasever&arch=$basearch
+#metalink=https://mirrors.fedoraproject.org/metalink?repo=epel${releasever_minor:+-z}-$releasever&arch=$basearch

疑問点

AlmaLinux 10.1 以上になったとき

epel-z-10 を指定してメタデータファイル取得した結果 /epel/10.0/ のファイルを取りに行くのなら、OS が 10.1 以上になったときにバージョン不一致がおこらないのか。
10.1 のときにも epel${releasever_minor:+-z}-$releasever は epel-z-10 に展開されるような気がする。メタデータファイル内の URL が /epel/10.1/ でないとまずそうだが、このままでいいのだろうか？

その後

この問題の修正が入った python3-dnf-4.20.0-14.el10_0.alma.1 が出ていた。