https://wiki.centos.org/About/Building_8
Table of Contents
CentOS 8 Rough Status Page
Red Hat Enterprise Linux 8 was released on 2019-05-07, and everyone is waiting to find out when the CentOS rebuild will occur. This document is meant to cover general questions and timeline for what is happening.
A CentOS major release takes a lot of planning and changes in tooling as it is based on a much newer version of Fedora than previous versions. This means that everything from the installer, packages, packaging, and build systems need major overhauls to work with the newer OS. This means that there is always a ramp up period depending on the changes needed to make a rebuild work. The differences between EL-8 and EL-7 are no exception as the kernel has changed drastically, the repository format has added 'modules' and RPMS have grown many features that EL7 and before do not have. About the only item which has not drastically changed between EL7 and EL8 is the init system which is still systemd. [This is a first as EL5 had SysV, EL6 had Upstart, and EL7 had Systemd].
General Steps
Steps needed to make a CentOS rebuild usually follow these steps:
- Red Hat makes the sources available.
- This used to be done via src.rpms but 7 changed to git repos
- In 8 CentOS has partnered closer with Fedora and will be sharing git repos with the Fedora system
- The pushes from Red Hat started on 2019-05-07 and ended 2019-05-08
- CentOS needs to look at the sources and determine what is needed to build these packages
- The rpm format has added items like Suggests which change some tooling requirements
- The packaging format has moved from yum to dnf4/yum4 which added modularity. Modules are an additional hurdle because they allow parallel available versions of software but not parallel installability (aka you can build perl-5.24 and perl-5.26 and all perl modules need to be compiled against both sets.) Module stream versions are tied to certain timestamps which means you can't rebuild the RHEL or Fedora and get the exact same version name.
- There are always packaging loops which need to be worked out. You need golang-(X-1) to build golang-X but golang-(X-1) doesn't exist yet.. how do you build a version and break the loop?
- CentOS needs to set up a build system which can allow for these changes.
- While CentOS can use the Fedora build system as a template, there are items in it which don't make sense for CentOS.
- The EL-8 beta was useful but there are still major changes which need rethinking
- CentOS needs to go through the source code and find out all the places where debranding is needed.
- No you can't just "sed s'/Red Hat/CentOS/' (someone always offers that)
- There are times when you do replace and times when you don't.
- Builds can start occurring through the system
- This usually requires a multi-loop as you do a build to get started
- Then rebuild that core with itself
-
Then add some more and possibly repeat 1 && 2 a couple of times.
- Then you can start building out the rest of the packages
- The installer usually takes a certain amount of work to get packaged together.
- Some things need additional patches
- Some things just need to be ordered correctly
- Some things like shim signatures for Secure Boot take outside review by signing authority
- QA work can begin
- with testing of packages by themselves or building from them
- with installer testing for smoke tests
- Usually some sort of RC work is done
- A final build is released
The above is a 'you asked the people trying to build the train when it will arrive' guide. That said, every release is different and the order and additional steps get found and added each time.
Current Build Status
In the above roadmap, we are currently somewhere in the middle of step 5 but as part of that, still finding things to fix up for step 4.
|
|
The current status of all builds can be seen on CentOS Linux 8 Builder |
|
|
|
Packages that have failed to build (patches are welcome, send to the centos-devel mailing list) can be seen on Failed Builds |
|
Architectures
Main architectures
The following arches are built automatically in parallel in our new Build System :
- x86_64 (w/ i686 multilib)
- ppc64le (Little Endian)
- aarch64 (ARM64, ARMv8)
Responsibility, Owner: CentOS Core SIG
AltArch
The following architecture (not existing upstream, so more difficult to boostrap) is also actually being worked, on, but mainly based on a combination of Fedora 27/28 pkgs that can be used to bootstrap the el8 beta rebuild and then iterating loops until we can include that architecture in our Koji Build System . Update : bootstrap phase is done, so now you can follow builds on Armhfp Build System
- armhfp (ARM32, ARMv7 - aka armv7hl)
Responsibility, Owner : CentOS SIG-AltArch
Current Timeline
|
Item |
Started |
Ended |
Status |
|
Sources pushed to CentOS Git |
2019-05-07 |
2019-05-08 |
DONE |
|
Source code evaluation |
2019-05-07 |
YYYY-MM-DD |
Ongoing |
|
New Build System Setup |
2019-05-07 |
2019-05-08 |
DONE |
|
Debranding patches added |
2019-05-07 |
YYYY-MM-DD |
Ongoing |
|
Artwork Requested |
2019-03-07 |
2019-05-07 |
DONE |
|
2019-05-09 |
YYYY-MM-DD |
Ongoing |
|
|
Build Loop 0 |
2019-05-07 |
2019-05-?? |
Ongoing |
|
Build Loop 1 |
YYYY-MM-DD |
YYYY-MM-DD |
Not started |
|
Build Loop N |
YYYY-MM-DD |
YYYY-MM-DD |
Not started |
|
Installer work |
YYYY-MM-DD |
YYYY-MM-DD |
Not started |
|
QA work |
YYYY-MM-DD |
YYYY-MM-DD |
Not started |
|
RC work |
YYYY-MM-DD |
YYYY-MM-DD |
Not started |
|
Release work |
YYYY-MM-DD |
YYYY-MM-DD |
Not started |
Definitions
- DONE - Step is completed
- Ongoing - Work is progressing
- Not started - This step may requires work from another step to reach some completion or requires time from person who is working on other parts.
- Build loop 0 - Getting an initial set of packages together which can then build more packages
- Build loop 1 - Using the smallest set of packages to build a larger set which can then build more packages
- Build loop N - I really don't know how many loops this is going to be.. so we will use N nomenclature.
- Installer work - there are usually some work needed to make the installer actually work with various things like secure boot or different fonts or 'oh they fixed that in an upgrade.img.. let us just short cut and put that here.'