Frequently Asked Questions (FAQ)

Extra Packages for Enterprise Linux (EPEL) is an initiative within the Fedora Project to provide high quality additional packages for CentOS Stream and Red Hat Enterprise Linux (RHEL). EPEL packages will also likely work with other distributions that target RHEL compatibility.

As part of the Fedora packaging community, EPEL packages are 100% free/libre open source software (FLOSS).

A large number of contributors and users of Fedora and Enterprise Linux want to work within Fedora to provide these packages.

The Fedora Project is a user of EPEL packages within the Fedora infrastructure itself. The Fedora Project is in a position to know the pain of not having a desired piece of software included in the RHEL distribution, and also a unique position to do something about it. Although RHEL is derived from Fedora, only a commercially supported subset of Fedora derived packages are included in the RHEL distribution. By sponsoring the EPEL project, Fedora contributors and users gain in many ways.

No. EPEL is a volunteer effort from the Fedora community. Just like Fedora itself, Red Hat hosts infrastructure for this project and Red Hat engineers are involved as maintainers and leaders but there are no commercial support contracts or service level agreements provided by Red Hat for packages in EPEL.

EPEL provides packages for CentOS Stream 10, CentOS Stream 9, Red Hat Enterprise Linux 9, and Red Hat Enterprise Linux 8. EPEL packages will also likely work with other distributions that target RHEL compatibility. Packages for earlier versions of CentOS Stream and RHEL are no longer provided because these versions are end of life.

No. EPEL is purely a complementary repository that provide add-on packages. EPEL packages will not conflict with any of the channels that it builds against, with limited exceptions (see conflicts in compat packages). Those specific channels are listed in the EPEL Policy.

It is permitted for EPEL to provide an alternative non-modular package to any package found only in a non-default RHEL module.

EPEL will coordinate with other channels/products to minimize any conflicts, but may replace or cause issues with other channels.

Refer to the EPEL package maintenance and updates policy for all the details.

Packages are peer reviewed against extensive packaging guidelines before being imported into the repository. Only updates that fix important bugs get pushed to the stable repository directly. Other updates hit a testing repository first and get released as an EPEL scheduled update in parallel with the EL scheduled updates. Packages often are tested in Fedora, too. The Fedora Packaging Guidelines and QA team back up all these efforts, helping to avoid errors. There are also discussions for more strict QA policies. Do participate and help us.

Ideally EPEL packages are maintained as long as the corresponding RHEL release is supported. However, EPEL is a volunteer effort, and a package maintainer can retire their EPEL branch at any time.

The only way to be sure is to do it yourself, which is coincidentally the reason EPEL was started in the first place.

Software packages in EPEL are maintained on a voluntary basis. If you want to ensure that the packages you want remain available, get involved directly in the EPEL effort. More experienced maintainers help review your packages and you learn about packaging. If you can, get your packaging role included as part of your job description; EPEL has written a generic description that you can use as the basis for adding to a job description.

We do our best to make this a healthy project with many contributors who take care of the packages in the repository, and the repository as a whole, for all releases until RHEL closes support for the distribution version the packages were built for. That is ten years after release (currently) — a long time frame, and we know a lot can happen in ten years. Your participation is vital for the success of this project.

Software and hardware vendors are encouraged to get involved in EPEL. For more information, read the ISV/IHV Perspective.

Packages are not automatically branched for each EPEL version. Each package must be branched by a packager for each particular release, and packagers may or may not be interested in EPEL 9 while they were interested in EPEL 8. If you are an EPEL 9 user and want to see a particular package added, it’s a good idea to ask the existing EPEL or Fedora maintainer. This lets the current maintainer know that there are real users who would benefit from the package (instead of simply guessing at the size of the user base).

To request an EPEL package for a particular EPEL branch, follow the EPEL package request steps.

Yes. There are people that use EL distributions on their home desktop or similar scenarios because Fedora’s release and updates cycle is faster than required for them. Some of those people want to play games or use other non-enterprise oriented software. Having such packages in the repository doesn’t affect anyone that uses EL distributions for other needs.

We require maintainers to take ownership and commit to maintaining the packages in the long term. Merely rebuilding all the packages automatically has higher potential for packages being broken or orphaned.

If the package is added to RHEL it must be retired from EPEL as it is no longer an "extra package for enterprise linux". There is some automation in place to file a ticket to give the EPEL maintainer a heads up; see the EPEL Package Retirement Process for more information.

Follow the instructions on the getting started page.

EPEL packages are located at the main mirror. There are mirrors available at mirror list.

The snapshots of the EPEL repository are available in an EPEL archive. Those are useful when a package was removed from EPEL, e.g. because the package was added into a later RHEL version and you have not yet migrated to the latest RHEL version.

The main fedora download server is currently ipv4 only.

It is recommended that you find the closest ipv6 mirror from the mirror list.

If you must connect directly to a fedora ipv6 download server, go here.

You can find help or discuss issues on the epel-devel mailing list or IRC channel #epel on libera.chat. Report issues against EPEL via Bugzilla. More options are available to communicate with EPEL.

All EPEL packages are signed with an official EPEL gpg-key. The public key IDs can be found at https://getfedora.org/security/. The keys are included in epel-release and dnf will ask you to import it the first time you install an EPEL package.

If you want to find out if a package comes from EPEL, use a query such as this:

Or you can install and run the 'keychecker' script to list all packages signed with a particular key as well as which repo they came from.

EPEL is just one of several add-on repositories with RPM packages for RHEL. It is not an official repository. The different repositories serve different user bases or follow different ideas.

Just like RHEL itself, EPEL in reality is more a "downstream" in the sense that Fedora is upstream and EPEL, just like Red Hat, takes packages for its product that are constantly developed, tested and receive feedback in Fedora. Red Hat, through their sponsorship for the Fedora project and participation of Red Hat maintainers, continues to back EPEL, but Red Hat has not endorsed EPEL or commercially supported it.

The EPEL maintainers are well aware that EPEL can’t serve all needs, and that other repositories are likely needed, for types of software the Fedora project won’t provide, which currently includes packages for EPEL with a rolling release model or non-free and patent encumbered software.

Anyone may contribute to EPEL. If you are using RHEL or compatible spin-offs, and you have the required skills for maintaining packages or are willing to learn, you are welcome to contribute.

You have to follow the same process as Fedora except that you request an EPEL branch such as epel8 or epel9.

Look here for the procedure used to get a Fedora package in EPEL.

No. You can if you want, or you can ask someone else to maintain the package in EPEL for you. In some cases, you may be approached by a current EPEL maintainer who wants to maintain your package in EPEL.

Please see this page for information about getting a free RHEL subscription for EPEL package maintenance.

All Fedora packagers can request EPEL branches in Git via the normal procedure. Please keep in mind that by building your packages in EPEL we expect that you are aware of the special EPEL guidelines and policies and that you will adhere to them. You should also plan to maintain the packages for the near future — ideally for several years, or for the full planned lifetime of EPEL. Remember that RHEL has a planned lifetime of 10 years.

You may want to look into formalizing your packaging role in your company or other organization. If you can do that, this generic job description may help. Aside from making sure that you are recognized for the value you give your organization, formal role recognition ensures that your organization has someone continuing to maintain the package, even if someone new is in the role.

It is the maintainer’s responsibility to ensure that their EPEL packages work on RHEL. Please see this page for information about getting a free RHEL subscription for EPEL package maintenance.

The plan is to have one primary maintainer per package who is responsible for making certain that the package enhancements applied to one tree find their way into the other trees (for example, Fedora devel).

This maintainer decides what makes sense to apply for the package in general. New EL branches for new EL releases are normally created from the associated Fedora branch on which the EL release is based. Therefore, the EL maintainer has a genuine interest in getting enhancements merged into Fedora.

Most likely they will build unchanged. However, there are specific items to consider. All your build requirements in the package must be part of RHEL or EPEL.

You will need to request a buildroot override in bodhi.

The easiest ways to do this are to either use the RHEL developer subscription or check the RHEL package manifests.

You can also check the package source repos in the CentOS Stream GitLab space. Note that a GitLab branch corresponds to the same major version of RHEL, e.g. the c9s branch for RHEL 9. If a branch has a dead.package file, that means it was removed during development of that RHEL version and is thus eligible for EPEL.

See here how to get a Fedora package in EPEL.

There is a short term and a long term solution. These two solutions should be used together.

When EPEL 8 was launched, it came together with the EPEL 8 Modular repo as an effort to bring modular packages to EPEL. After years of struggle, it was decided to disable by default the EPEL 8 Modular repository on October 31st 2022, and then to archive the repository from Febraury 14th 2023 onward. Currently there is no plan to bring modularity back to EPEL.

If you want to bring a package that is distributed as modular in Fedora you will need to create a non-modular version of the package.

Get it in Fedora first. This isn’t a strict rule, but all the EPEL packages need to meet the Fedora packaging guidelines. If people want it in EPEL, they probably want it in Fedora as well.

If it is in Fedora, and you are the maintainer, branch and build it as you would any other Fedora release.

If it is in Fedora, and you are NOT the maintainer, follow the EPEL package request steps.

Simply go through the review process for Fedora and specify only EL targets for the initial import. Due to technical reasons, a main branch for Rawhide will always be created. Therefore retire the package directly in Fedora Rawhide to avoid confusion. But note that maintaining packages in Fedora has many advantages for you, you should consider maintaining the package in both Fedora and EPEL if it makes for the package to be in Fedora.

Please follow the Package Retirement Process.

Please do not try and push your packages directly to stable unless they are security updates or critical bug fixes. This is enforced by epel rel-eng/signers who will change your request to testing unless your update meets the criteria for pushing to stable.

Normal updates spend a weeks in testing before being pushed to stable. If enough people test those updates and give your package sufficient karma in bodhi it can be pushed to stable before that week is up.

There were a lot of long discussions in the months of EPEL about using repotags or not. Lots of people from inside and outside of Fedora and EPEL, as well as maintainers from other repositories, participated in those discussions. No real agreement could be found as to whether the benefits outweigh the disadvantages - part of the problem was that people sometimes couldn’t agree on the benefits or disadvantages repotags have (or if there are any). The final decision in three voting sessions (one done by FESCo before EPEL had a Steering Committee and twice done by EPEL’s first Steering Committee) was to go without repotags in EPEL.

EPEL is always willing to discuss cooperation with other parties and repositories and encourages maintainers to do so whenever possible.

Mixing different RPM repositories that were not designed to be mixed can lead to incompatibilities that often result in dependency resolution problems in dnf. Sometimes it even happens that software is not working as expected if libraries and applications come from different repositories. EPEL is designed as an add-on repository for RHEL. The best way to avoid problems is to avoid mixing EPEL with other third party repositories that have conflicting packages on the same system. Some people nevertheless do it and the dnf priorities plugin can help to avoid the worst problems.

If you encounter a problem where packages from EPEL are incompatible with another repository, or lead dnf to bail out during dependency resolution, please report a bug in Bugzilla and contact the maintainer of the other repositories. The EPEL project encourages its maintainers to solve such problems together with the maintainers from other repositories in order to find a solution that is acceptable for both sides. However, there is no guarantee such a solution can or will be found in every case, as technical solutions to solve a repository-mixing issue might have side-effects or drawbacks for one of the repositories involved.