ELN Extras

ELN-Extras is essentially an extension of Fedora ELN, with the primary difference being that the content in ELN-Extras will be defined by the Fedora/EPEL community, while ELN’s content is largely decided upon by Red Hat management. This will offer users the opportunity to make sure their applications will work on upcoming releases of RHEL as well as providing a bootstrapping mechanism for EPEL. It will be far easier and quicker to get a compose of EPEL N+1 out the door if the initial packages have already been built for ELN-Extras.

You are responsible when your package fails to build on ELN Extras. Remember to check your packages on the ELN Status Page. ELN Extras packages get rebuilt much more frequently than in EPEL.

How to Add a Package to ELN Extras

Adding packages to ELN Extras, is the same as adding them to ELN. The only difference is that any Fedora packager can add packages to ELN Extras, while only a handful of people can add packages to ELN.

You add binary packages by creating and submitting workloads for Content Resolver. You submit them as pull requests at content resolver input. The workloads go in the config directory.

Once the workloads have been merged, Content Resolver works through all the dependencies of the workload, subtracts those packages that are already in ELN, and displays it in its ELN Extras view.

After Content Resolver has worked it work, the ELN build process takes that list and adds it to the ELN Extras build list.

Workloads

The full documentation on what goes in a workload yaml file can be found as comments in the example workload yaml file.

The create your initial workload yaml file, take that example yaml file, rename it, edit it, then submit it as a pull request.

The example workload yaml has an example for everything. But we don’t need everything for ELN Extras.

Workload Required Sections

  • document: feedback-pipeline-workload

    • This exact line, do not change it

  • version: 1

    • This exact line, do not change it

  • name: <workload name>

    • Keep this short, spaces are allowed

  • description: <workload description>

    • Longer description, but must be on one line

  • maintainer: <FAS and/or Github ID>

    • Who will be the maintainer of the packages in this workload for ELN and EPEL.

    • Do not put someone elses name as maintainer without their permission.

  • labels: eln-extras

    • Although multiple labels can be listed, for eln-extras, only list the one

  • packages:

    • List of binary packages in the workgroup

    • DO NOT LIST SOURCE PACKAGE NAMES IN PACKAGES LIST.

    • LIST ALL THE BINARY PACKAGES YOU NEED.

    • If you are listing a package in the optional arch specific package list, do not list it here.

Workload Optional Sections

  • arch_packages:

    • If you have a package that is not built on all arches, you need to list it on all the arches it it built on.

    • All noarch packages go in the regular package: section.

  • options:

    • If you need to use the options, you can.

Workload Unused Sections

  • modules_disable:

    • We do not have modules in ELN Extras

  • groups:

    • We do not have groups in ELN Extras

  • package_placeholders:

    • We do not process package_placeholders in ELN Extras

ELN-only packages

ELN-only packages can also be added to ELN Extras. One example is https://docs.fedoraproject.org/en-US/epel/epel-faq/#rhel_8_has_binaries_in_the_release_but_is_missing_some_correspondingdevel_package._how_do_i_build_a_package_that_needs_that_missingdevel_package[-epel packages] which are often used to provide subpackages that have been unshipped or otherwise excluded in RHEL. These packages can be added to ELN Extras, with some additional caveats: * similarly to regular -epel packages, the package needs to only produce the needed subpackages and nothing else * the package needs to be manually built for ELN from the "eln" branch in dist-git * the SRPM name has to be different from the corresponding Rawhide package (example) * the SRPM name has to be added to the exclusion list in ELNBuildSync to avoid accidental rebuilds (example) * the needed subpackages need to be added to Content Resolver for ELN Extras as usual (example)

ELN Extras Frequently Asked Questions

Can I add any or all Fedora packages to ELN-Extras?

You are attaching your name as the supporter of these packages. You will be submitting these workload packages as pull requests. The ELN SIG will review the pull requests and ask questions if things look strange or incorrect. So, yes, if you are willing to support a package, it can be any Fedora package not in ELN. And while we are not putting a firm limit on the number of packages you can add to ELN Extras, the SIG is reviewing them and will not merge requests that seem excessive for the person requesting them.

If someone has already added a package to their workload, can I have the same package in mine?

Yes. Content Resolver is setup to deal with a package in more than one workload, or a dependency in more than one workload. It will show what workloads list, or require what packages. It even takes a guess on who should be the owner of the package.

Want to help? Learn how to contribute to Fedora Docs ›