# Update on EPEL-8 Status
## Why is EPEL-8 Taking So Long (tl;dr:)
1. Getting koji to work smoothly with modules has been hard. A multi-level fix has had to
be worked to get it working in staging.
* Needed a way to split out default modules to deal with koji merge options.
[
Grobisplitter](https://github.com/puiterwijk/grobisplitter) was written to do this
* [Koji](https://pagure.io/koji) needed further patching to deal with src.rpms with
same NVR but different targets (some python2 and python3 come from same src.rpm but were
built in different times).
* DNF reposync from RHEL-7 would delete the wrong files if you tried the ``--newest``
(fixed.)
* DNF does not know how to reposync modules if it is not the local arch. Code Ready
Builder is not always in sync with packages in main trees. If you need a -devel and it
isn’t in CRB, then you have to wait until it is there to build something.
2. As a couple of fixes landed in mergerepo and koji, we are re-evaluating how we do
builds in the next stage of building.
## Introduction
In May of 2019, Red Hat released their 8.0 release of Red Hat Enterprise Linux (RHEL).
Usually, the Extra Packages for Enterprise Linux (EPEL) group would have a beta available
at that time or sooner. With RHEL-8, it has taken a lot longer to get things rolling.
## Repository Changes
EPEL packages are built inside of the Fedora Projects' build infrastructure. This is
done by downloading the packages from Red Hat's public Content Delivery Network (CDN),
and then having the Fedora artifact build system (koji) use the release as an external
build channel. Koji looks at packages in a different way than other build commands like
'mock' do. Where mock is meant to just build packages, koji is designed about
auditing the entire lifecycle of a package. In other words, if you want to know how a
package in Fedora 12 was built and all its children interacted over time in the
buildroots.. you can do that with enough work and the koji databases. With mock you have a
couple of log files which tell you what was pulled into a buildroot but how those were
built would require you finding their log files, etc etc. A developer can also download
those packages and look at them to see what was in them and how they were built.
The strength of koji is that you can have a credible chain of builds to know where things
came from. However this doesn't work too well with building packages for EPEL where
koji doesn't know where the RHEL kernel came from. Koji uses mergerepo to look at the
external packages provided, determines the src.rpm they would come from and determines
what the latest version it would use from each. From this it creates a 'buildroot'
which it will use to build packages from. This has worked pretty well for building
packages from RHEL-5,6, and 7. The major downside has been where someone built a package
with the same src.rpm name which koji then decides is the master no matter if a newer
version shows up in RHEL.
This all changed with modularity. Koji really only has a rudimentary idea of rpms and
repositories.. it has zero idea about modules and the rules it has used to determine what
an external package is are thrown out with modules.
1. Packages with different names may come with from the same src.rpm. In RHEL-8 many
python27 and python36 packages have the same parent src.rpm but were in different build
times. Koji's standard repo comparison mode will choose one or the other.
2. Packages may have the same names-version-releases but were built in different module
streams (say perl-5.26 and perl-5.24) Koji would then choose a package depending on
whatever had the largest src.rpm which meant it could try to build a buildroot with
perl-5.24 perl modules but perl-5.26 as the master perl.
If a developer uses mock to build a package with default repositories, mock calls dnf
which knows about modules and does the right thing. In the case where you want it to do
the 'wrong' thing you can also over-ride mock to do that. With koji, further tools
are needed to make this work. If you are building a new module, then the Modular Build
System (MBS) sits on top of koji and tells koji what to do. It will look at the module
yaml file and turn on/off various modules so that it can build in what is needed. To build
non-modular packages, other fixes are needed. One of these is called Ursa-Major which was
a set of scripts to pull in needed data from a third database and pull things in as
needed. However, this was not adopted in Fedora for general use so the EPEL group looked
for something different.
The temporary solution written by Patrick Uiterwijk is called grobisplitter
(
https://github.com/puiterwijk/grobisplitter) which relies on the fact that modules are
virtual repositories embedded in a master repository. Grobisplitter takes this fact, and
uses it to break out 'real' repositories for each module. So the RHEL-8 repository
will look like
```
ant:1.10:820181213135032:5ea3b708:x86_64
container-tools:rhel8:8000020190416221845:2ffa3d27:x86_64
container-tools:rhel8:820190211172150:20125149:x86_64
freeradius:3.0:8000020190425181943:75ec4169:x86_64
freeradius:3.0:820190131191847:fbe42456:x86_64
gimp:2.8:820181213135540:77fc8825:x86_64
go-toolset:rhel8:820190208025401:b754926a:x86_64
httpd:2.4:8000020190405071959:55190bc5:x86_64
httpd:2.4:820190206142837:9edba152:x86_64
idm:client:820190227213458:49cc9d1b:x86_64
inkscape:0.92.3:820181213140018:77fc8825:x86_64
javapackages-runtime:201801:820181213140046:302ab70f:x86_64
javapackages-tools:201801:820181217165704:dca7b4a4:x86_64
llvm-toolset:rhel8:820190207221833:9edba152:x86_64
mailman:2.1:820181213140247:77fc8825:x86_64
mariadb:10.3:820190206164045:9edba152:x86_64
mariadb:10.3:820190314153642:9edba152:x86_64
maven:3.5:820181213140354:5ea3b708:x86_64
mercurial:4.8:820190108205035:77fc8825:x86_64
merged_repo
mysql:8.0:820190104140943:9edba152:x86_64
nginx:1.14:820181214004940:9edba152:x86_64
nodejs:10:820190108092226:9edba152:x86_64
non_modular
perl-App-cpanminus:1.7044:820181214184336:e5ce1481:x86_64
perl-DBD-MySQL:4.046:820181214121012:6bc6cad6:x86_64
perl-DBD-Pg:3.7:820181214121102:6fcea174:x86_64
perl-DBD-SQLite:1.58:820181214121133:6bc6cad6:x86_64
perl-DBI:1.641:820190116185335:fbe42456:x86_64
perl-FCGI:0.78:820181214153815:fbe42456:x86_64
perl-YAML:1.24:820181214175558:8652dbeb:x86_64
perl:5.26:820181219174508:9edba152:x86_64
php:7.2:820181215112050:76554e01:x86_64
postgresql:10:820190104140132:9edba152:x86_64
python27:2.7:8000020190410132513:c0efe978:x86_64
python27:2.7:820190212161047:43711c95:x86_64
python36:3.6:8000020190410133122:593c47b3:x86_64
python36:3.6:820190123171828:17efdbc7:x86_64
redis:5:820181217094919:9edba152:x86_64
rhn-tools:1.0:8000020190425124933:6ec19280:x86_64
rhn-tools:1.0:820190321094720:e122ddfa:x86_64
ruby:2.5:820190111110530:9edba152:x86_64
rust-toolset:rhel8:820181214214108:b09eea91:x86_64
satellite-5-client:1.0:820190204085912:9edba152:x86_64
scala:2.10:820181213143541:2b79a98f:x86_64
squid:4:820181213143653:9edba152:x86_64
subversion:1.10:820181215112250:a51370e3:x86_64
swig:3.0:820181213143944:9edba152:x86_64
varnish:6:820181213144015:9edba152:x86_64
virt-devel:rhel:820190226174025:9edba152:x86_64
virt:rhel:8000020190510171727:55190bc5:x86_64
virt:rhel:8000020190516125745:55190bc5:x86_64
virt:rhel:820190226174025:9edba152:x86_64
```
In the above, each of those names is the module name, and grobisplitter would then put
the appropriate files in each sub repository. The problem with this version is that we end
up with multiple repositories with some of them being 'non-default' modules.
Building against a non-default module causes problems for someone trying to install that
package. It would replace packages from a different module than was wanted. Changes to
grobisplitter were made at
https://github.com/smooge/grobisplitter to allow only default
modules to be published.
From this we were able to start deploying a devolved tree in the Fedora staging koji
(
https://koji.stg.fedoraproject.org/) The first set of fixes needed was to make it so koji
could work with multiple artifacts coming from the same src.rpm. Instead of using the
standard mode for resolving differences, we import RHEL-8 repositories with a bare mode
which is supposed to use external repository data to determine what should be pulled in.
However, we found that koji still gets confused if multiple versions of a package are in
the repo data. Say your repository contains both ``glibc-*-2.1-2`` and ``glibc-*-2.2-2``.
Koji would pull in ``glibc-devel-2.1-2`` and try to match it against ``glibc-2.2-2``. This
of course caused builds to fail.
At first the fix looked to be having the reposync from the CDN pull only the latest data.
However we ran into problems with either the RHEL-7 or RHEL-8 reposync deleting data we
wanted to keep depending on the options used. Part of this was due to module data and part
of it was due to some bugs in dnf's reposync with other architectures. At this point,
it looked like one of two things needed to be done. One, grobisplitter needs to learn
about package order and pull in just the latest package into a non-modular repo. Two,
another layer of indirection is needed where after we split out all the repositories we
use reposync again to just pull from the grobisplit repositories. In this case we do so
with a ``-n`` and only have the latest packages. The second option seemed easier to pursue
as most of the grobisplitter toolkit should become irrelevant when the next generation of
Ursa-Major comes out.
## Code Ready Problems
We ran into our next major problem with RHEL-8 repositories when we found that -devel and
-lib rpms in Code Ready Builder were not always in sync with their parent packages in
BaseOS/AppStream. This means that if your build is wanting kernel-devel and the BaseOS is
4.9-11 but the CRB version is 4.9-10 then koji has no way to supply the dependency for
you. The major culprit currently is that the virt module has had multiple updates but the
virt-devel module has not had any updates.
## Build Over View
1. RHEL-8 packages are reposync from cdn onto
infrastructure.fedoraproject.org
<
http://infrastructure.fedoraproject.org> nfs directory.
2. grobisplitter runs on
grobisplitter01.phx2.fedoraproject.org
<
http://grobisplitter01.phx2.fedoraproject.org> to break out each module into
repositories in a ``$date/$arch/$repos`` layout.
3. createrepo is run on ``$date/$arch``
4. a symbolic link is set to ``$date`` staged
5. ``reposync -n -d`` is run against ``staged/$arch`` to ``latest/$arch``
6. createrepo is run on ``latest/$arch``
7. koji points to ``latest/$arch``
8. packages can be built
9. packages can be signed
10. bodhi and other items do their parts
11. we compose
12. ...
13. profit?
## What Are The Next Steps?
Currently we are looking to have our internal beta done by July 1st. At that point, we
will work on documenting what we have done, and reimplementing the tool changes in
production. At which point, developers will be able to make branch requests to releng to
make packages available and builds should start flowing. From that we will probably find
new things which will need fixes in either spec files or build infrastructure.
A GANNT chart of our current production plan is provided below.
![](https://i.imgur.com/bGiAnHk.png)
--
Stephen J Smoogen.
Thanks for the detailed writeup! I briefly checked out your staging Koji and noticed that
there are a huge number of module-* tags. Is this going to be addressed? At least have a
way to hide them in the UI?
Thanks,
-Mat
--
Mátyás (Mat) Selmeci
Open Science Grid Software Team / Center for High-Throughput Computing
University of Wisconsin-Madison Department of Computer Sciences