On 07/01/19 07:57, Stephen John Smoogen wrote:
> # 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
