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.
- Status:WORKING DRAFT:
- 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.
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.
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.
- Coordinator: Stephen Smoogen
- Impacted: Matthew Miller
- Release Engineering:
- Additional Tool Development:
- CentOS Coordination: Brian Stinson
The following assumptions are in place:
- Fedora will be able to use the following RHEL-8 channels to build EPEL Packages
- Code Ready Linux Builder (CRLB)
- Data for determining modules can be easily determined so that createrepo can be used
- This data can be used to build non-modular and modular packages
- This data will consumable
- That EPEL will not need to rebuild additional packages which are made from src.rpms for the packages in Base, Appstream, CRLB
- EPEL will look at using CentOS packages when they become available to fill those gaps.
- EPEL users are slow to migrate to new versions. This allows us some time to experiment.
- EPEL users are vocal about problems. This means that while emotional taxing, we will get feedback quickly.
- Old Website for EPEL: https://fedoraproject.org/wiki/EPEL
- Place where EPEL will move to: https://pagure.io/epel/
- Red Hat Enterprise Linux Packages: ftp://ftp.redhat.com/redhat/rhel/rhel-8-beta
- Red Hat Code Ready Linux Builder: https://developers.redhat.com/blog/2018/11/15/introducing-codeready-linux-builder/
- Fedora Modularity Documentation: https://docs.fedoraproject.org/en-US/modularity/
- Fedora Modularity Upstream: https://docs.pagure.org/modularity/
- Determine the buildroot requirements. The buildroot is the bare minimum packages that are needed to build the majority of packages. While it can be based on the Fedora 29 minimum buildroot, the EPEL-8 one has some major caveats.
- While we are able to use the packages from RHEL-8, we are not able to share them with the world. This means that koji can not import the packages but only knows about them via external repositories.
- There are specific rules and limitations in Koji rules for el-8 hidden external build roots
- In addition to not knowing enough about the packages in RHEL-8, the buildsystem has no knowledge about the modules in them. This will require gathering data, and then importing fake modules from RHEL-8 into MBS.
- After these are done, we can start to determine what default packages/modules are and what will be in a minimal buildroot.
- Write further tools which will take 8.x RHN channel and creates a 'composed' buildroot for koji to work on. It would be useful for the tool to report when packages are being over-written by ones koji does know about so that we can stop packages getting replaced by koji built ones.
- Both modularity and koji developers feel there will be further problems that will need solutions but what they are needs the above to be put in place.
- Determine new directory layout for compose/ship. A proposal has been sent to the EPEL mailing lists for feedback which would change directory structure for EPEL-7 and possibly 6 as the tools to compose builds should be uniform for least maintenance.
- Need to set up appropriate branches and tool changes for EPEL-8.
- Release engineering tools ( bodhi, koji, pdc, pkgs and many other tools) will need to know about the new branches and targets.
- Each branch for EPEL has caused problems with parts of the Fedora build system in the past. Various tools and cleanup have to be discovered to work around it.
- Fedpkg will need code changes and updates in various existing source code places
- Determine architectures to build against
- Easy to build
- Hard to build
- Currently the Code Ready Linux Builder is only available to accounts with RHN and it only has a subset of packages which were used to build RHEL-8 with. There may be packages which EPEL will need which need to be added to CRLB or we need to work out a method of communicating our 'over-rides' with.
- Need to consult Bugzilla maintainers for changes needed
- Package name
- Business rules
- Establish policies for which packages are branched into EPEL-8
- A problem with current builds in EPEL-6 and EPEL-7 are when a package is in x86_64 but is not in other architecture channels. In the past, EPEL has allowed for the rebuild of the required packages for those architectures. However this causes problems because now koji KNOWS about this rebuild and will use that one even if there is a newer NVR in the RHEL-8 channels.
- Establish policies for how modules are branched into EPEL-8
- EPEL and RHEL may have the same modules
- EPEL and RHEL may not have module stream collisions (aka EPEL streams must be named clearly they are from EPEL).
- Setup policies for package 7->8 bootstrapping (w/o review). Some packages going into EPEL need a review and other times they do not. The policies here need to be revamped as it has slowed down getting bootstrapping in the past.
- Establish tool to block packages in 8.0
- See what we can move back to RHEL-7
- Meet with consumers and producers of the current EPEL tools
- Get current problems they want fixed
- Get expectations of how consumers want to get packages
- Get expectations of how producers want to put packages in EPEL
- Put together proposals for changes to EPEL-6/7 trees to meet problems that affect EPEL-8
- Put together talk for