On Tue, Aug 26, 2025 at 10:11 AM Lance Albertson <la...@osuosl.org> wrote: > > > > On Mon, Aug 25, 2025 at 8:15 PM Carl George <c...@redhat.com> wrote: >> >> On Mon, Aug 25, 2025 at 7:20 PM Lance Albertson <la...@osuosl.org> wrote: >> > >> > We just noticed something rather odd while working on adding EL10 support >> > to our infrastructure. >> > >> > Previously, we had tested and verified that we could install >> > nagios-plugins-http, but today that's no longer the case if you're on >> > AlmaLinux 10 pointed at the 10.0 EPEL repo. >> >> How did you previously set up EPEL? nagios-plugins has only been >> built in EPEL 10.1, so RHEL 10.0 and Alma 10.0 systems shouldn't see >> it available. >> >> https://bodhi.fedoraproject.org/updates/?search=&packages=nagios-plugins&releases=EPEL-10.0&releases=EPEL-10.1&releases=EPEL-10 >> >> If you're using a custom repo definition, it needs to match to >> commented out baseurl examples in the official epel-release to ensure >> you get packages targeting the appropriate minor version. If you were >> previously able to install nagios-plugins-http with your repo setup, >> that sounds like it was misconfigured to use 10.1 (pub/10) instead of >> 10.0 (pub/10z) > > > We had it pointed to "10" which likely pointed to "10.1" (up until yesterday) > which didn't have any issues until.. (see below) > >> >> > The reason we're pointing directly at 10.0 is due to some issues we ran >> > into with clamav linking against newer openssl libraries using the 10.1 >> > branch. I would expect packages that were in 10.0 to remain, but is that >> > not the case anymore? >> >> Indeed, clamav in EPEL 10.1 is built against openssl 3.5.1, but in >> EPEL 10.0 is built against openssl 3.2.2. Subtle differences like >> this are why we have minor versions in EPEL now. > > > This breaks on AlmaLinux if pointed to 10.1 (or 10 at the time), still also > breaks pointing to 10.2: > > clamav-1.4.3-1.el10_1.x86_64 > > $ clamscan > clamscan: symbol lookup error: /lib64/libclamav.so.12: undefined symbol: > EVP_MD_CTX_get_size_ex, version OPENSSL_3.4.0 > > IMHO this shouldn't break on AlmaLinux 10 like it did.
This is the same type of problem that can happen if you tried to install a RHEL 10.1 package on RHEL 10.0. RHEL's compatibility guarantees are designed around third party software building on a minor version and then continuing to work on subsequent minor versions. There are no guarantees that a package will work on earlier minor versions than the one it was built on. This is explicitly called out in the RHEL Application Compatibility Guide. https://access.redhat.com/articles/rhel10-abi-compatibility#:~:text=An%20application%20is,newer. > > An interesting note, the AlmaLinux 10 container uses 10.0: > > [root@2452e995dddb /]# dnf repolist -v epel > Last metadata expiration check: 0:03:50 ago on Tue Aug 26 15:03:19 2025. > Repo-id : epel > Repo-name : Extra Packages for Enterprise Linux 10 - x86_64 > Repo-status : enabled > Repo-revision : 1756173563 > Repo-updated : Tue Aug 26 01:59:37 2025 > Repo-pkgs : 17771 > Repo-available-pkgs: 17771 > Repo-size : 16 G > Repo-metalink : > https://mirrors.fedoraproject.org/metalink?repo=epel-z-10&arch=x86_64 > Updated : Tue Aug 26 15:03:19 2025 > Repo-baseurl : > rsync://ftp-osl.osuosl.org/fedora-epel/10.0/Everything/x86_64/ (218 more) > Repo-expire : 86400 second(s) (last: Tue Aug 26 15:03:19 2025) > Repo-filename : /etc/yum.repos.d/epel.repo > Total packages: 17771 > > The epel.repo has this line: > > metalink=https://mirrors.fedoraproject.org/metalink?repo=epel${releasever_minor:+-z}-$releasever&arch=$basearch Yes, that's the correct behavior. The repo name in that metalink expands to epel-z-10 on RHEL and Alma, and epel-10 on CentOS (based on whether releasever_minor is defined). Mirrormanager is configured to return 10.0 mirror paths for the former, and 10.2 mirror paths for the latter. That will change over time with new minor versions. For a custom repo config using baseurl instead of metalink, see the commented out baseurl example in epel.repo. #baseurl=https://download.example/pub/epel/$releasever${releasever_minor:+z}/Everything/$basearch/ That release section expands to 10z on RHEL and Alma, and 10 on CentOS. These are symlinks on the mirrors to 10.0 and 10.2 respectively, following the same pattern as mirrormanager. > > So if we're on AlmaLinux, should we be using the minor branch of epel to > ensure ABI compatibility? If that's the case, then I will contact the package > maintainer to add the 10.0 tag to get it included. Yes, that is how epel-release is designed. Using the wrong minor version repo may work initially or for some packages, but will eventually lead to problems. The maintainer can't manually add tags to their builds, only releng can do that (or more specifically, koji admins). But it would be inappropriate to add the 10.0 tag to a 10.1 build, as you have noticed with clamav. The correct solution is to either wait for Alma 10.1 or ask the maintainer to specifically create a 10.0 build. They can do this by running: fedpkg request-branch epel10.0 git fetch git switch epel10.0 fedpkg build fedpkg update This is the same process that a maintainer would follow to add a package to f41 that was initially only available for f42 and newer. > > Thanks- > > -- > Lance Albertson > Director > Oregon State University | Open Source Lab > -- > _______________________________________________ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue -- Carl George -- _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
