From Fedora Project Wiki

Revision as of 17:59, 16 February 2019 by Smooge (talk | contribs)

This is a shorthand list of items we are needing to cover for building EPEL-8 in Fedora Infrastructure for the Fiscal Year 2020.

his is a shorthand list of items we are needing to cover for building EPEL-8 in Fedora Infrastructure for the Fiscal Year 2020.

Document Details

  • Point of contact: Stephen Smoogen
  • Implementation Schedule: 2019-06-01
  • Release Date: 2019-06-01


  • Make a version of EPEL available by end of March for the beta of RHEL-8.
    • Version will work out tools needed to make builds possible using modules
    • Version will test new compose rules for EPEL trees using a Stuff and Updates tree.
    • Version will test out new compose paths
  • Make a larger version of EPEL-8 available soon after the General Availability of RHEL-8
    • Assume that for 8.0 that builds of modules may not be available but tested in alternate tree
  • Make EPEL-8 fully able to build modular sets by release of RHEL-8.1
    • Test scripts to archive old releases and compose new ones at this time.


With Red Hat Enterprise Linux (RHEL) 8 Beta released, it is time to evaluating making a version of EPEL for it. As with any major RHEL release, there are major changes which affect what can and can not be done in a release. Where in RHEL-7 there were changes in the init program moving from Upstart to systemctl, this release has added modular rpm package sets which change how packages can be built.

Modules are a tool which allows one to have parallel availability of different package sets. One can set up a system and choose to have php-7.2 OR php-7.4 installed with appropriate sub-modules as needed. These are done via the dnf command which has the needed logic to work out needed dependencies and conflicts. In order for the koji system to know this, there is also the Module Build System (MBS) which interprets and keeps track of this higher level repo data. For Fedora packages and modules which are completely built within koji this is all put together, however EPEL packages are built from artifacts which koji has no idea about. These are the Red Hat Enterprise Linux packages which koji and the build systems see as outside repositories. Since these packages were not built in the Fedora Build Infrastructure, neither koji nor MBS know enough about the packages which would cause build failures at times.

In order to work around this additional tools need to be built which can ferret out the information from the RHEL metadata in order to allow modules to be both pulled into various build roots and also have additional modules built on top of those pre-existing modules.

Strategic Fit

EPEL is used by a very large number of systems around the world and is part of the lifecycle of packages moving from Fedora Linux into the Red Hat Enterprise Linux ecosystem. Having Fedora packages and tools available in EPEL is seen as useful for both Fedora and Red Hat in maintenance of their userbase.

People involved

This project impacts a number of application or other projects. Here is a quick list of the different projects involved and their point of contact.


The following assumptions are in place:

  1. Fedora will be able to use the following RHEL-8 channels to build EPEL Packages
    1. Base
    2. Appstream
    3. Code Ready Linux Builder (CRLB)
  2. Data for determining modules can be easily determined so that createrepo can be used
    1. This data can be used to build non-modular and modular packages
    2. This data will consumable
  3. That EPEL will not need to rebuild additional packages which are made from src.rpms for the packages in Base, Appstream, CRLB
    1. EPEL will look at using CentOS packages when they become available to fill those gaps.
  4. EPEL users are slow to migrate to new versions. This allows us some time to experiment.
  5. EPEL users are vocal about problems. This means that while emotional taxing, we will get feedback quickly.

Additional Links

Task Breakdown

  1. Determine buildroot requirements
    1. Koji rules for el-8 hidden external build roots
    2. import fake modules from RHEL-8 into MBS
    3. determine what default packages/modules are
    4. determine what is in 8.0 buildroot.
    5. create tool which will take 8.x RHN channel and creates a 'composed' buildroot for koji to work on
    6. TBD
  2. Determine new directory layout for compose/ship
    • /pub/epel/releases/8.x/Stuff
    • /pub/epel/releases/8.x/Modular
    • /pub/epel/updates/8.x/Stuff
    • /pub/epel/updates/8.x/Modular
  3. Need to branch for EL8
  4. Need koji tags
  5. FPDC entries (is FPDC ready???)
  6. Discover rel-eng tasks for setup/cleanup that no one remembers
  7. Fix fedpkg/centpkg to understand new EPEL layout, branch names, etc
  8. Determine architectures to build against (s390?)
  9. Need to work out open communication paths with Red Hat internal teams in charge of Code Ready Linux Builder for packages..
  10. Need to consult Bugzilla maintainers for changes needed
    1. Package name
    2. Business rules
  11. Establish policies for which packages are branched into EPEL-8
  12. Establish policies for how modules are branched into EPEL-8
  13. Setup policies for package 7->8 bootstrapping (w/o review)
  14. Establish tool to block packages in 8.0
  15. See what we can move back to RHEL-7