releng

#11589 The epel9-next build repository contains older versions of packages
Closed: Can't Fix by smooge. Opened by churchyard.

Closed: Can't Fix
Reopen Issue
  • Describe the issue
$ cat /etc/yum.repos.d/koji-epel9-next.repo
[koji-epel9-next]
name=koji-epel9-next
baseurl=https://kojipkgs.fedoraproject.org/repos/epel9-next-build/latest/$basearch/
enabled=0
$ repoquery -q --repo=koji-epel9-next rpm
rpm-0:4.16.1.3-19.el9.x86_64
rpm-0:4.16.1.3-21.el9.x86_64
rpm-0:4.16.1.3-22.el9.x86_64
rpm-0:4.16.1.3-23.el9.x86_64
rpm-0:4.16.1.3-25.el9.x86_64

This leads to epel9-next builds that will gladly take an older version of a package (from RHEL 9.X) rather than the most uptodate version form c9s.

From https://koschei.fedoraproject.org/package/python3-rpm?collection=epel9-next --> https://koji.fedoraproject.org/koji/taskinfo?taskID=104153092 --> https://koji.fedoraproject.org/koji/taskinfo?taskID=104153160 --> https://kojipkgs.fedoraproject.org//work/tasks/3160/104153160/root.log

Installing:
...
 rpm-sign-libs                 x86_64   4.16.1.3-23.el9           build    21 k
...
Downgrading:
 rpm                           x86_64   4.16.1.3-23.el9           build   538 k
 rpm-build                     x86_64   4.16.1.3-23.el9           build    73 k
 rpm-build-libs                x86_64   4.16.1.3-23.el9           build    89 k
 rpm-libs                      x86_64   4.16.1.3-23.el9           build   306 k
Skipping packages with broken dependencies:
 rpm-sign-libs                 x86_64   4.16.1.3-25.el9           build    21 k
Transaction Summary
================================================================================
Install    91 Packages
Downgrade   4 Packages
Skip        1 Package
 Problem: package rpm-sign-libs-4.16.1.3-25.el9.x86_64 from build requires rpm-libs(x86-64) = 4.16.1.3-25.el9, but none of the providers can be installed
  - cannot install both rpm-libs-4.16.1.3-23.el9.x86_64 from build and rpm-libs-4.16.1.3-25.el9.x86_64 from @System
  - cannot install both rpm-libs-4.16.1.3-25.el9.x86_64 from build and rpm-libs-4.16.1.3-23.el9.x86_64 from build
  - cannot install the best candidate for the job

Would it be possible to configure the epel9-next build repository to only has the latest package available?

  • When do you need this? any time

  • When is this no longer needed or useful? (2027/05/31)

  • If we cannot complete your request, what is the impact?

Packages in EPEL 9 Next are built against older versions -- being untested or even uninstallable on CentOS Stream 9.

This might be a problem of c9s itself:

[c9s-baseos]
name=CentOS Stream 9 - BaseOS
metalink=https://mirrors.centos.org/metalink?repo=centos-baseos-9-stream&arch=$basearch&protocol=https,http
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-centosofficial
gpgcheck=1
repo_gpgcheck=0
metadata_expire=6h
countme=1
enabled=0
$ repoquery -q --repo=c9s-baseos rpm
rpm-0:4.16.1.3-19.el9.x86_64
rpm-0:4.16.1.3-21.el9.x86_64
rpm-0:4.16.1.3-22.el9.x86_64
rpm-0:4.16.1.3-23.el9.x86_64
rpm-0:4.16.1.3-25.el9.x86_64

However, I belive that whatever syncs those packages to Koji should be able to limit them to the latest versions (and that will save space as well).

So as far as I know, none of those packages in the EPEL-next are from RHEL-9. What you are seeing is a problem with CS9 itself.. and what rsync says should be in the repo

The file which does this is ansible/roles/batcave/files/centos-9s-sync and it just rsyncs direct from the CentOS Stream repos. When stuff goes away there, it should go away in the CS9 repo. The flags --delete --delete-delay --delay-updates do this so that we don't have to remake the repository data which would need extra flags to deal with modules and such.

This looks like it was a problem with the upstream CentOS Stream repository and not with anything Fedora 'maintains'. If this is still a problem, it needs to be opened against CentOS Stream.

Metadata Update from @smooge:
- Issue close_status updated to: Can't Fix
- Issue status updated to: Closed (was: Open)
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.