Bug 2158538

The current rawhide branch builds against EPEL9 successfully.

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

This package is already part if RHEL-9 Buildroot repository.

I'm not seeing it.  Can you point me to it by chance?

The Fedora package is python3-fs from python-fs...src.rpm which I cannot find in any EL9 repos.  I see the sources on gitlab but it doesn't seem like the package is published anywhere.

Packages that entirely within the RHEL buildroot (i.e. no subpackages shipped in BaseOS, AppStream, or CRB) are eligible to be added to EPEL [0].  Based on the CentOS Stream 9 build [1], the only subpackage python-fs creates is python3-fs, and it is not shipped in RHEL.  Therefore this is a valid request and the epel9 branch can be added to this package by running:

    fedpkg request-branch epel9

[0] https://docs.fedoraproject.org/en-US/epel/epel-policy/#_policy
[1] https://kojihub.stream.centos.org/koji/buildinfo?buildID=12775

Carl,
I was not expecting such reply here. This confuses me. The only way I was knowing till date is that move the requested package to CRB and now you are saying something different here. I really wish there could have been a simple FAQ entry https://docs.fedoraproject.org/en-US/epel/epel-faq/ which says what to do when one requests some (sub-)package which is part of RHEL Buildroot repository.

I only grepped for word "Buildroot" in https://docs.fedoraproject.org/en-US/epel/epel-policy/#_policy without reading it so I believe its not addressing directly what to do when someone requests buildroot package available in EPEL? If it really addresses, Please tell me which line say it so.

The general public can't see the RHEL buildroot.  More importantly, EPEL packages do not build against it.  They only build against baseos, appstream, and crb [0].  That's why EPEL policy is that a package is eligible for EPEL as long as it isn't in baseos, appstream, or crb.  I don't think it makes much sense for EPEL to document RHEL repos that do not concern it.  If you'd still like to see an EPEL FAQ item covering this, please send a pull request to add it [1].

Moving a buildroot package to crb is a separate process that is sometimes necessary when packages from the same source package are already shipped in baseos, appstream, or crb.  EPEL packages are checked for eligibility based on the source package name by both fedpkg and fedscm-admin.  If any package from a source package is in baseos, appstream, or crb, then the EPEL branch request is rejected.  For example, RHEL9.0 had glslang in appstream and glslang-devel in the buildroot.  EPEL9 packages could not build against glslang-devel.  Since glslang couldn't be added to EPEL9 because of the source package name conflict, the best solution was to move glslang-devel from buildroot to crb [2].  This request process is documented [3].

I think the simplest solution would be to add the epel9 branch to the Fedora package (which is allowed under the current conditions) as Jonathan has requested.  If you prefer to add it to crb instead, it would become ineligible for EPEL9, which is also ok but that prevents you from having community co-maintainers.


[0] https://docs.fedoraproject.org/en-US/epel/epel-policy/#_policy
[1] https://pagure.io/epel/blob/main/f/modules/ROOT/pages/epel-faq.adoc
[2] bug 2056017
[3] https://docs.fedoraproject.org/en-US/epel/epel-policy-missing-sub-packages/#long_term

(In reply to Carl George 🤠 from comment #6)
> The general public can't see the RHEL buildroot.  More importantly, EPEL
> packages do not build against it.  They only build against baseos,
> appstream, and crb [0].  That's why EPEL policy is that a package is
> eligible for EPEL as long as it isn't in baseos, appstream, or crb.  I don't
> think it makes much sense for EPEL to document RHEL repos that do not
> concern it.  If you'd still like to see an EPEL FAQ item covering this,
> please send a pull request to add it [1].
> 
> Moving a buildroot package to crb is a separate process that is sometimes
> necessary when packages from the same source package are already shipped in
> baseos, appstream, or crb.  EPEL packages are checked for eligibility based
> on the source package name by both fedpkg and fedscm-admin.  If any package
> from a source package is in baseos, appstream, or crb, then the EPEL branch
> request is rejected.  For example, RHEL9.0 had glslang in appstream and
> glslang-devel in the buildroot.  EPEL9 packages could not build against
> glslang-devel.  Since glslang couldn't be added to EPEL9 because of the
> source package name conflict, the best solution was to move glslang-devel
> from buildroot to crb [2].  This request process is documented [3].
> 
> I think the simplest solution would be to add the epel9 branch to the Fedora
> package (which is allowed under the current conditions) as Jonathan has
> requested.  If you prefer to add it to crb instead, it would become
> ineligible for EPEL9, which is also ok but that prevents you from having
> community co-maintainers.
> 
> 
> [0] https://docs.fedoraproject.org/en-US/epel/epel-policy/#_policy
> [1] https://pagure.io/epel/blob/main/f/modules/ROOT/pages/epel-faq.adoc
> [2] bug 2056017
> [3]
> https://docs.fedoraproject.org/en-US/epel/epel-policy-missing-sub-packages/
> #long_term

Thank you very much I think this cleared my confusion. I see fonttools package's binary packages are all in Buildroot so this qualifies it to become EPEL9 package. I will start building dependencies first and then fonttools in EPEL9.

FEDORA-EPEL-2023-12f0b1612f has been submitted as an update to Fedora EPEL 9. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-12f0b1612f

FEDORA-EPEL-2023-12f0b1612f has been pushed to the Fedora EPEL 9 testing repository.

You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-12f0b1612f

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

FEDORA-EPEL-2023-12f0b1612f has been pushed to the Fedora EPEL 9 stable repository.
If problem still persists, please make note of it in this bug report.