[CentOS-devel] Discussion: Open technical questions concerning SIG content for RHEL releases

Wed Dec 14 23:04:05 UTC 2022
Peter Georg <peter.georg at physik.uni-regensburg.de>

Dear all,

There has been an inquiry to the CentOS Board to clarify how long SIGs 
can expect to be able to build against RHEL build targets [1]. This is 
necessary to allow SIGs themselves to communicate expected lifecycle of 
their content to users.
The outcome of this, in summary, is that SIGs should be able to build 
against RHEL until it reaches EOL (end of Maintenance Phase) + 30 days 
(no access to ELS content). This policy follows the one used by EPEL.

Note: It is (obviously) still up to every single SIG to decide if and 
for how long they want to support a particular RHEL (or CentOS Stream) 

This inquiry also included respectively raised some technical questions. 
These technical questions are not to be decided by the CentOS Board. In 
[2] it has been recommended to discuss these on centos-devel. So let's 
do that.

I want to start with two open questions which I do know of. In case 
there are other open question concerning this matter please raise them here.

First open question is where to push content produced by SIGs for RHEL8 to.

To better understand the issue, let me summarize the current situation, 
for which we first need to define the used format for tags in CBS:

where <el> can currently be 7,8,8s,9,9s

Packages tagged for -testing are pushed to:

Packages tagged for -released are push to:

If el = 8 or 8s:
debuginfo rpm packages:
src.rpm packages:
Everything else:

If el = 9 or 9s:

For src.rpm <arch> is source.

Note: Although it is not relevant for the discussion, in fact on the 
mirrors the suffix "s" of <el> is replaced by "-stream".

This currently is all fine. However it is planned that the 
infrastructure currently used for packages built for 8 or 8s will 
disappear once CentOS Stream 8 and CentOS Linux 7 are EOL (June 30th, 
2024). So in case any SIG decides to produce content for RHEL 8 after 
that date packages can not be distributed properly anymore.

Only using the -testing tag and thus https://buildlogs.centos.org is not 
really an option as it would probably produce too much load on these.
My proposal: After CentOS Stream 8 went EOL (May 31st, 2024), which is 
the same date as the end of the Full support phase of RHEL 8, at least 
the -release tag of all RHEL 8 build targets is locked and SIGs have to 
opt-in in case they want to build content for RHEL 8 during its 
Maintenance Support phase (End: May 31st 2029) for a particular build 
target. For these, tagging for -release will then push content to 
i.e. the same location as used for 9 and 9s.
This gives SIGs one month for all required changes before the currently 
infrastructure disappears.

Of course this means additional work for SIGs and Infra. However at some 
point the location where to push content to has to be changed before the 
currently used infrastructure disappears. Choosing an earlier date would 
result in work for SIGs who do not want to continue providing any 
packages once RHEL 8 enters Maintenance Support phase anyway.

The second open question concerns the centos-release-* packages provided 
by SIGs to allow users to easily consume SIGs' content. For 8s and 9s 
the CBS tags extras<el>-extras-common-{candidate,testing,release} are 
used to build these packages. This repository is added in CentOS Stream 
8 and 9.
For packages build for RHEL 8 and 9 there is currently no common way to 
provide any means of easing the process to consume SIGs' content.
My proposal to fix this is by adding 
extras<el>-extras-common-{candidate,testing,release} for <el> = 8 and 9, 
i.e., using the same system as currently used for 8s and 9s.

To further ease the process I propose to introduce a package named 
centos-release-extras which contains the repository config pointing to 
the content of the tags extras<el>-extras-common-{testing,release} (only 
-release enabled by default) and the CentOS-SIG-Extras GPG key. The 
centos-release-extras packages itself would be built in the 
extras<el>-extras-common-el<el> build target. Users of RHEL would then 
only need to install this single package to allow them to easily install 
any other centos-release-* packages. Obviously someone needs to maintain 
the centos-release-extras package. I volunteer to maintain this package.

[1]: https://git.centos.org/centos/board/issue/82
[2]: https://pagure.io/centos-infra/issue/1002