Bug 2331259

I do not currently maintain any EPEL packages and do not wish to start.  I am happy to grant comaintainer status to anyone who wishes to maintain EPEL branches, though.

FEDORA-EPEL-2025-e4b15038dd (subunit-1.4.4-4.el10_0) has been submitted as an update to Fedora EPEL 10.0.
https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-e4b15038dd

The generated packages are missing the dependency on python3-junitxml, so I have opened bug #2336216 to get it (it seems to build fine).

(In reply to Romain Geissler from comment #3)
> The generated packages are missing the dependency on python3-junitxml, so I
> have opened bug #2336216 to get it (it seems to build fine).

python-junitxml is already built in epel10.  And subunit built fine without it.

Where does this dependency come from? Are you saying there's an installtime/runtime dependency and that a 'Requires: python-junitxml' needs to be added to the .spec?

> python-junitxml is already built in epel10.

It was not when I wrote the message, but now it is, that was pretty fast. It's been submitted recently to testing via https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-b5e4e21b5a

> And subunit built fine without it.

Yes but as seen in other packages, what is installed inside a mockbuild are only the build time dependencies, not the runtime dependencies. So it's possible to generate packages which aren't installable in the end.

> Where does this dependency come from?

Extract from my message in the fedora update https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2025-e4b15038dd:

Error:
 Problem 1: conflicting requests
  - nothing provides python3dist(junitxml) needed by subunit-filters-1.4.4-4.el10_0.noarch from @commandline
 Problem 2: package python3-subunit-test-1.4.4-4.el10_0.noarch from @commandline requires subunit-filters = 1.4.4-4.el10_0, but none of the providers can be installed
  - conflicting requests
  - nothing provides python3dist(junitxml) needed by subunit-filters-1.4.4-4.el10_0.noarch from @commandline


so it's a runtime dependency of subunit-filters.

I am not really an experienced packager, so I don't know if we shall add explicitly a 'Requires: python-junitxml' but I would naively expect that we want to avoid listing all dependencies explicitly and rely on the different %py* rpm macros to generate that for us, no ?

(In reply to Romain Geissler from comment #5)
> Error:
>  Problem 1: conflicting requests
>   - nothing provides python3dist(junitxml) needed by
> subunit-filters-1.4.4-4.el10_0.noarch from @commandline
>  Problem 2: package python3-subunit-test-1.4.4-4.el10_0.noarch from
> @commandline requires subunit-filters = 1.4.4-4.el10_0, but none of the
> providers can be installed
>   - conflicting requests
>   - nothing provides python3dist(junitxml) needed by
> subunit-filters-1.4.4-4.el10_0.noarch from @commandline
> 
> 
> so it's a runtime dependency of subunit-filters.
> 
> I am not really an experienced packager, so I don't know if we shall add
> explicitly a 'Requires: python-junitxml' but I would naively expect that we
> want to avoid listing all dependencies explicitly and rely on the different
> %py* rpm macros to generate that for us, no ?

yeah, there's a borked 'Requires: ...'  for python3-junitxml in the .spec. I will respin the package.

(In reply to Kaleb KEITHLEY from comment #6)
> 
> yeah, there's a borked 'Requires: ...'  for python3-junitxml in the .spec.

No, not borked. It's just an idiom I haven't seen before.

Once python3-junitxml gets pushed to stable and there's a compose that error will go away.

If you're building packages in koji that need it you'll have to create an Override for it.

(In reply to Romain Geissler from comment #5)
> I am not really an experienced packager, so I don't know if we shall add
> explicitly a 'Requires: python-junitxml' but I would naively expect that we
> want to avoid listing all dependencies explicitly and rely on the different
> %py* rpm macros to generate that for us, no ?

Ideally, we let the %py* macros generate dependencies, yes.  In this case, though, upstream has not provided the metadata to indicate the dependency.  If you grep for junitxml in the subunit sources, you can see where it is used.  It might be possible to downgrade the dependency from Requires to Recommends, however, since it is only needed if the subunit2junitxml script is used.  We could even split that script out into a separate subpackage that carries the dependency if it is troublesome.

Now that python-junitxml was build for EPEL 10, there is no problem anymore no, we can keep everything as is.

FEDORA-EPEL-2025-e4b15038dd has been pushed to the Fedora EPEL 10.0 testing repository.

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

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

FEDORA-EPEL-2025-e4b15038dd (subunit-1.4.4-4.el10_0) has been pushed to the Fedora EPEL 10.0 stable repository.
If problem still persists, please make note of it in this bug report.