epel

#256 Older epel9-next build would shadow newer epel9 build when used as dependency
Opened by salimma. Modified

Open
Close Issue

For end users, epel9-next works as expected: it's another repo, together with epel9, and whichever has the highest NEVRA satisfying a dependency would get used.

For buildroot though, if a package is present in epel9-next it will be used regardless of if it's older than the version in epel9.

This makes it wasteful for Koji and makes for additional work for the packager at best - e.g. for Rust SIG we jointly maintain all packages so we can just rebase and rebuild in epel9-next - but for other language ecosystem where the package might have a sole maintainer, this would block the process of building the dependent package unnecessarily

(And is a surprising behavior).

cc @decathorpe who ran across this issue with Rust packages earlier, and @kevin who might know how to fix it on the Koji side

Example: rust-bat failed because bytesize in epel9-next was older than bytesize in epel9

https://koji.fedoraproject.org/koji/taskinfo?taskID=108395982

root.log attached

Fixed by building an updated rust-bytesize in epel9-next as well
https://koji.fedoraproject.org/koji/packageinfo?packageID=27886
rust-bat-epel9-next-108395982-x86_64-root.log

Metadata Update from @salimma:
- Issue tagged with: meeting

(see also https://pagure.io/releng/issue/11540#comment-874789 and the whole ticket)

If you have a package in epel9-next, and then put it into epel, you need to clean up your epel9-next packages.
I have a script and clean them up once a RHEL release, usuall a month after the release, but I don't do it during the 6 months in-between.
During that 6 months in-between, I clean up my own packages, but tend to leave everyone elses alone because I don't know what they are doing.

If you have a package in epel9-next, and then put it into epel, you need to clean up your epel9-next packages.

Right. We probably could document this better, but this is how it always was since EPEL 8 Next was introduced. The koji tag is set up so anyone has sufficient permissions to run the koji untag commands.

I wonder if Rust packages did actually get "cleaned up" after the RHEL 9.2 release? The problems I'm seeing all stem from the fact that builds that were done pre-RHEL-9.2 in epel9-next for older versions of packages are superseding post-RHEL-9.2 updates for newer versions that were only pushed to epel9.

We discussed this in the committee meeting. We're going to document not only that this is what koji does, but also how epel8/9-next package maintainers can clean up (untag) their own packages from epel8/9-next so they don't get caught by this.
Edited by tdawson

I wonder if Rust packages did actually get "cleaned up" after the RHEL 9.2 release?

It's possible I missed it. I remember being worried about the rust stuff.

I'll rerun my script (without doing the untag) and see what it looks like.

This is part of what I am going to put in the documentation:

If you built a package in epel-next and an updated package is in regular epel, 
you should untag the older package from epel-next.  
This keeps the epel-next buildroot clean for the next time you need to build a package.
Unlike regular Fedora and EPEL packages, epel-next packages can be untagged 
by the person who built them.  
Below is an example.
koji untag-build epel9-next plasma-nm-5.27.4-1.el9.next

Metadata Update from @tdawson:
- Issue untagged with: meeting

FYI, After merging everything from epel9-next into epel9 after the release of RHEL 9.3, I untagged everything from epel9-next, and it seems to have worked as expected.

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/epel/steering/issues/256

Please continue any further discussion there.
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.