Bug 2313930

Hi Carl

Thanks for checking. I had requested an epel10 branch and built the package successfully in scratch, pushed and built successfully. Does this mean that:

- We have to src.fpo assignee *manually* after a successful branch request.
- There is no check on "Requires" during build, only "Buildrequires".
- There is is no check against FTI on bodhi push to stable.

That is not how we should set up things.

You solved the first problem manually (thanks), and I'll request epel10 builds for the missing requires. But how/where do we guard against FTI early enough? Some tmt stuff (the config always scraed me off, too many layers)?

OK, I got myself in some dependency hell here. I'm trying stuff in here:

https://copr.fedorainfracloud.org/coprs/mjg/impressive-epel/

Trying to file requests now ...

> - We have to src.fpo assignee *manually* after a successful branch request.

Usually no.  For my packages I've never seen the EPEL assignee set to orphan, but I have seen it happen occasionally to other packages.  I'm not sure of the exact steps that would cause the situation.  Perhaps there previously was a separate EPEL assignee, and they later removed themselves from the package?  Or maybe at one point the package was completely orphaned, and when you adopted it the default assignee was set to you, but not the EPEL assignee?  But I'm just speculating.

> - There is no check on "Requires" during build, only "Buildrequires".

Correct.  Ideally, all the requires are also buildrequires in order to run the test suite, or otherwise do some kind of "smoke test" in %check.  Python packages are required to do one or the other.

https://docs.fedoraproject.org/en-US/packaging-guidelines/Python/#_tests

> - There is is no check against FTI on bodhi push to stable.

Correct.  Unfortunately there is nothing in our current pipeline that prevents an uninstallable package with missing requires from being built and pushed to the repos.

> But how/where do we guard against FTI early enough? Some tmt stuff (the config always scraed me off, too many layers)?

Fedora does two things: they run a non-blocking installability check on bodhi updates (see the automated tests tab of a Fedora bodhi update), and they routinely check existing packages and file FTI bugs.  We currently have neither for EPEL.  I'm working on changing this.  I don't think TMT is the best solution for this, as that would be opt-in, and I believe these checks should be run by default.

Thanks for starting the work to get this resolved and filing the corresponding bugs.  I'll try to keep an eye out for the ones that I have access to and try to help.

Since the dependency tree for this includes a few packages that haven't gotten any traction yet, would you be ok with me untagging the epel10 build for now?  That will remove it from the repo and avoid users seeing the uninstallable package.  The dist-git branch would still be active and it can be published again by creating a new bodhi update (once the dependencies are available).

(In reply to Carl George 🤠 from comment #4)
> Since the dependency tree for this includes a few packages that haven't
> gotten any traction yet, would you be ok with me untagging the epel10 build
> for now?  That will remove it from the repo and avoid users seeing the
> uninstallable package.  The dist-git branch would still be active and it can
> be published again by creating a new bodhi update (once the dependencies are
> available).

Yes, please do, I meant to request this. Thanks!

In more general terms, I think that the new concept of "build the next EPEL early" (to increase package availability" and the concept of "each EPEL starts new" (as opposed to rawhide->branched->released" do not go well together when packagers do not feel obliged to build a package for EPEL n+1 when they have done so for EPEL n: It forces everyone to hunt down all dependencies each time we have a new EPEL. I know, it's not every 6 months, but still does not help convince Fedora packagers build for EPEL.

Alright, the build has been untagged.

Regarding the other comments, each EPEL version starting new is a necessity for several reasons.

- Packages are added or removed in new RHEL major versions, changing what is eligible to be in EPEL.  Branch requests are when we validate that.
- We don't want to assume that a maintainer who is interested in maintaining one EPEL branch will be interested in maintaining the next.
- Libraries in the base operating system change quite a bit in the years between RHEL major versions.  We can't assume that branching from rawhide will work every time, as sometimes we need to branch from older branches to ensure compatibility.
- EPEL branches have a much longer lifecycle than Fedora, so opt-in branching is a useful signal that maintainers believe the branch is appropriate for most if not all of that lifecycle.

There has been various ideas over time about how to improve on the branching friction.  The most beneficial improvement is that we now automate the branching requests instead of waiting on RelEng to process them manually [0].  That helps with the actual branching mechanics, but not with permissions, so I always recommend to maintainers to co-maintain their dependencies whenever possible.  We also have the EPEL Stalled Request process [1] to add maintainers without resorting to a full Unresponsive Maintainer orphaning [2].  I'm sure there will be more ideas in the future to improve the situation further.

I don't think the early building makes this friction worse overall.  Ensuring all your dependencies are present will always have to be solved, no matter when you do it.  Naturally if you wait until a few years in there is a high likelihood that most or all of your dependencies will already be present without your interaction, but they're there because someone else dealt with the friction before you.

Anyways, thanks for the feedback on this.  We can probably work on the maintainer communications next time around to hopefully avoid the "do not feel obliged to build a package for EPEL n+1" sentiment you described.  We're preparing to officially announce EPEL 10 next week, so hopefully that improves things for EPEL 10.

[0] https://pagure.io/fedora-infra/toddlers/blob/main/f/toddlers/plugins/scm_request_processor.py
[1] https://docs.fedoraproject.org/en-US/epel/epel-policy/#stalled_epel_requests
[2] https://docs.fedoraproject.org/en-US/fesco/Policy_for_nonresponsive_package_maintainers/

FEDORA-EPEL-2025-881cbd849c (impressive-0.13.2-6.el10_1) has been submitted as an update to Fedora EPEL 10.1.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-881cbd849c

FEDORA-EPEL-2025-881cbd849c has been pushed to the Fedora EPEL 10.1 testing repository.

You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-881cbd849c

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-EPEL-2025-881cbd849c (impressive-0.13.2-6.el10_1) has been pushed to the Fedora EPEL 10.1 stable repository.
If problem still persists, please make note of it in this bug report.