I am not sure if this is possible because elinks is a buildroot-only package in RHEL-9.

This bug appears to have been reported against 'rawhide' during the Fedora Linux 37 development cycle.
Changing version to 37.

From what I can see, elinks is not in CRB, thus an EPEL 9 branch should be requestable.

elinks is not in CRB but it is in RHEL-9 buildroot, which I think should not overlap with EPEL.

This package has changed maintainer in Fedora. Reassigning to the new maintainer of this component.

May I kindly ask what actually prevents branching here?

Please branch and build elinks in epel9.

If you do not wish to maintain elinks in epel9, or do not think you will be able to do this in a timely manner, I would be happy to be a co-maintainer of the package (FAS robert); please add me through https://src.fedoraproject.org/rpms/elinks/adduser

This bug appears to have been reported against 'rawhide' during the Fedora Linux 38 development cycle.
Changing version to 38.

Like Kamil said, it is in RHEL-9 buildroot, it got there through ELN. Since it's already present in RHEL environment, the only way I know about is move it a level up to CRB.

No, the package is not in CRB, thus it qualifies for EPEL. I also would like to avoid CRB, if possible to have chances for rebasing elinks in EPEL through the RHEL 9 lifecycle.

Btw, I'm also going to take this RZBZ to the EPEL SIG meeting later today (for a cross-verification).

There are many (sub)packages that are not in CRB and cannot be in EPEL.  Inclusion of a (sub)package into CRB needs to be explicitly requested and approved by Red Hat.  See bug #1764048 for example.

I've taken this to the EPEL SIG meeting, see 21:08:10 until 21:12:06 at https://meetbot.fedoraproject.org/fedora-meeting/2023-02-22/epel.2023-02-22-21.00.log.html - a buildroot-only package with no (sub)packages shipped in RHEL shouldn't prevent EPEL branching (and this is IMHO what applies to elinks).

Based on this: Could somebody please file a branching request? Alternatively, I would also be happy to be a co-maintainer (FAS: robert) for EPEL. Thank you.

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].  It does not matter if the package is in the RHEL buildroot.  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

(In reply to Carl George 🤠 from comment #14)
> 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].

I did not know about this rule.  Thank you for clarifying it!
 
> [0] https://docs.fedoraproject.org/en-US/epel/epel-policy/#_policy

After reading that section twice, I was unable to find the above rule.  Unless I am blind, the whole page does not mention RHEL buildroot at all.  I would appreciate if the policy explicitly specified this case.

Can someone please also clarify (in the policy document?) whether EPEL9 doesn't collide with ELN in which 'elinks' is due to dependency of docbook?  
https://tiny.distro.builders/view-rpm--view-c9s--elinks.html

Thanks.

Content Resolver is wrong about the run-time dependency of docbook-utils-0.6.14-54.el9 on elinks:

% rpm -qp --requires --suggests https://kojihub.stream.centos.org/kojifiles/packages/docbook-utils/0.6.14/54.el9/noarch/docbook-utils-0.6.14-54.el9.noarch.rpm
/usr/bin/perl
/usr/bin/sh
docbook-dtds
docbook-style-dsssl >= 1.72
gawk
grep
perl(Getopt::Long) >= 2.01
perl(integer)
perl(strict)
perl(vars)
perl-SGMLSpm >= 1.03ii
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsZstd) <= 5.4.18-1
text-www-browser
which
lynx


The weak dependency on elinks was removed two years ago:

    https://src.fedoraproject.org/rpms/docbook-utils/c/93b8c6f32d969b9784f606361faf3f93309b8306?branch=rawhide

Branch created, Robert Scheck added as a contributor to the package.

> After reading that section twice, I was unable to find the above rule.  Unless I am blind, the whole page does not mention RHEL buildroot at all.  I would appreciate if the policy explicitly specified this case.

The RHEL buildroot is not public.  It's a Red Hat internal implementation detail.  EPEL (a fully public project) is not going to have documentation that references it.

> Can someone please also clarify (in the policy document?) whether EPEL9 doesn't collide with ELN in which 'elinks' is due to dependency of docbook?

The policy states that EPEL 9 is built against against the RHEL 9 "target base" (baseos, appstream, and crb) and that EPEL packages can't replace packages in that target base.  Any other repo is outside the scope of the policy.  We don't base whether a package is valid for EPEL on Content Resolver, we base it on the literal packages in RHEL (and for 9 and above, CentOS Stream).  You can see this implemented in both fedpkg [0] and fedscm-admin [1].  Requesting an EPEL branch for a package that is actually shipped in RHEL will be rejected.

[0] https://pagure.io/fedpkg/blob/177c80883ff9780edcba8f9b36865914541fe313/f/fedpkg/utils.py#_377-459
[1] https://pagure.io/fedscm-admin/blob/8dbaa380ce09079f0f0a1568f98448937d03c7e1/f/fedscm_admin/utils.py#_751-800

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

FEDORA-EPEL-2023-ad6de3044b 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-ad6de3044b

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

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