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) release.
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: <sig><el>-<project>-<version>-{candidate,testing,release}
where <el> can currently be 7,8,8s,9,9s
Packages tagged for -testing are pushed to: https://buildlogs.centos.org/centos/<el>/<sig>/<arch>/<project>-<version>/
Packages tagged for -released are push to:
If el = 8 or 8s: debuginfo rpm packages: https://debuginfo.centos.org/centos/<el>/<sig>/<arch>/<project>-<version>/ src.rpm packages: https://vault.centos.org/centos/<el>/<sig>/Source/<project>-<version>/ Everything else: http://mirror.centos.org/centos/<el>/<sig>/<arch>/<project>-<version>/
If el = 9 or 9s: http://mirror.stream.centos.org/SIGs/<el>/<sig>/<arch>/<project>-<version>/
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 http://mirror.stream.centos.org/SIGs/8/<sig>/<arch>/<project>-<version>/, 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
inline reply
On 15/12/2022 00:04, Peter Georg wrote:
Dear all,
<snip>
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.
That's the solution we'd need to discuss. Indeed mirror.centos.org and mirrorlist.centos.org can/will both disappear when CentOS Linux 7 itself will be EOL (around June 2024) At least mirrorlist.centos.org as current code works for 7 and 8s but starting from Stream 9 (and beyond) it's all hosted on Fedora MirrorManager. So mirrorlist.centos.org itself will be deprecated/removed completely (itself running on centos linux 7 nodes, so reason why it will be decommissioned at the same time)
For mirror.centos.org, don't know why we should continue to use it as all produced content around centos stream will then be pushed to the existing mirror.stream.centos.org infra.
So I guess your question is : where should the RHEL 8 SIG packages land if mirror.centos.org and mirrorlist.centos.org will be disappearing ?
I'd be tempted to propose something (open for comments) : starting from June 2024, they'd be pushed to https://mirror.stream.centos.org/SIGs/ ? (and so '8' directory as there is already a '9' one for content built against/for RHEL9 ) That would mean that normally mirrormanager would also start crawling about these and so switching from mirrorlist= to metalink= would normally work.
It would just need a modification in the sign+push process to point to new location (and eventually see if pushing to debuginfo/vault still makes sense or "consolidate" all content the same way it's done for 9/9s already)
<snip>
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.
<snip>
That's more or less the ticket you opened https://pagure.io/centos-infra/issue/643 but I'll let Brian answer that one
inline reply
On 16/12/2022 08.56, Fabian Arrotin wrote:
inline reply
On 15/12/2022 00:04, Peter Georg wrote:
Dear all,
<snip> > > > 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. >
That's the solution we'd need to discuss. Indeed mirror.centos.org and mirrorlist.centos.org can/will both disappear when CentOS Linux 7 itself will be EOL (around June 2024) At least mirrorlist.centos.org as current code works for 7 and 8s but starting from Stream 9 (and beyond) it's all hosted on Fedora MirrorManager. So mirrorlist.centos.org itself will be deprecated/removed completely (itself running on centos linux 7 nodes, so reason why it will be decommissioned at the same time)
For mirror.centos.org, don't know why we should continue to use it as all produced content around centos stream will then be pushed to the existing mirror.stream.centos.org infra.
Agree.
So I guess your question is : where should the RHEL 8 SIG packages land if mirror.centos.org and mirrorlist.centos.org will be disappearing ?
Yes.
I'd be tempted to propose something (open for comments) : starting from June 2024, they'd be pushed to https://mirror.stream.centos.org/SIGs/ ? (and so '8' directory as there is already a '9' one for content built against/for RHEL9 ) That would mean that normally mirrormanager would also start crawling about these and so switching from mirrorlist= to metalink= would normally work.
Sounds good to me. It is (almost) the same solution I proposed in the initial post anyway (except for the opt-in requirement):
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 http://mirror.stream.centos.org/SIGs/8/<sig>/<arch>/<project>-<version>/, 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.
It would just need a modification in the sign+push process to point to new location (and eventually see if pushing to debuginfo/vault still makes sense or "consolidate" all content the same way it's done for 9/9s already)
Sounds good. Concerning consolidation of debuginfo/vault: +1 for consolidation the same way it's done for 9/9s.
<snip>
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.
<snip>
That's more or less the ticket you opened https://pagure.io/centos-infra/issue/643 but I'll let Brian answer that one
Correct. It is somehow related. So added it here to be discussed on centos-devel.
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
Gentle reminder that the second question below has not been addressed yet. Any thoughts? Thanks for taking your time.
On 15/12/2022 00.04, Peter Georg wrote:
Dear all,
<snip>
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.
(Second) gentle reminder that the second question below has not been addressed yet. Any thoughts? Thanks for taking your time!
It'd also be helpful if anybody can provide any information on who I need to ping to get a decision on that matter. Thanks!
On 27/01/2023 12.38, Peter Georg wrote:
Gentle reminder that the second question below has not been addressed yet. Any thoughts? Thanks for taking your time.
On 15/12/2022 00.04, Peter Georg wrote:
Dear all,
<snip> > > 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
On 03/04/2023 19:03, Peter Georg wrote:
(Second) gentle reminder that the second question below has not been addressed yet. Any thoughts? Thanks for taking your time!
It'd also be helpful if anybody can provide any information on who I need to ping to get a decision on that matter. Thanks!
On 27/01/2023 12.38, Peter Georg wrote:
Gentle reminder that the second question below has not been addressed yet. Any thoughts? Thanks for taking your time.
On 15/12/2022 00.04, Peter Georg wrote:
Dear all,
<snip> > > 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
I'm not "authoritative" to answer that question, but why not simply just build your -release package in your tag, and let it go to mirror in that repository ? people using RHEL (or a rebuild) can just get it from there, the same way that people using RHEL are consuming EPEL : point to a mirror for the -release package and that's it ? (https://docs.fedoraproject.org/en-US/epel/#_el9)
Just my two cents :)
On 04/04/2023 13.58, Fabian Arrotin wrote:
On 03/04/2023 19:03, Peter Georg wrote:
(Second) gentle reminder that the second question below has not been addressed yet. Any thoughts? Thanks for taking your time!
It'd also be helpful if anybody can provide any information on who I need to ping to get a decision on that matter. Thanks!
On 27/01/2023 12.38, Peter Georg wrote:
Gentle reminder that the second question below has not been addressed yet. Any thoughts? Thanks for taking your time.
On 15/12/2022 00.04, Peter Georg wrote:
Dear all,
<snip> > > 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
I'm not "authoritative" to answer that question, but why not simply just build your -release package in your tag, and let it go to mirror in that repository ? people using RHEL (or a rebuild) can just get it from there, the same way that people using RHEL are consuming EPEL : point to a mirror for the -release package and that's it ? (https://docs.fedoraproject.org/en-US/epel/#_el9)
Just my two cents :)
In case there is never an answer by anyone who is "authoritative", that is a viable alternative. However I think the approach I suggested has several advantages for users, hence I'd like to further pursue it.
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Wed, Apr 5, 2023 at 6:07 AM Peter Georg peter.georg@physik.uni-regensburg.de wrote:
On 04/04/2023 13.58, Fabian Arrotin wrote:
On 03/04/2023 19:03, Peter Georg wrote:
(Second) gentle reminder that the second question below has not been addressed yet. Any thoughts? Thanks for taking your time!
It'd also be helpful if anybody can provide any information on who I need to ping to get a decision on that matter. Thanks!
On 27/01/2023 12.38, Peter Georg wrote:
Gentle reminder that the second question below has not been addressed yet. Any thoughts? Thanks for taking your time.
On 15/12/2022 00.04, Peter Georg wrote:
Dear all,
<snip> > > 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.
Are you asking to create and ship this package in the RHEL repos directly?
josh
On 05/04/2023 17.29, Josh Boyer wrote:
On Wed, Apr 5, 2023 at 6:07 AM Peter Georg peter.georg@physik.uni-regensburg.de wrote:
On 04/04/2023 13.58, Fabian Arrotin wrote:
On 03/04/2023 19:03, Peter Georg wrote:
(Second) gentle reminder that the second question below has not been addressed yet. Any thoughts? Thanks for taking your time!
It'd also be helpful if anybody can provide any information on who I need to ping to get a decision on that matter. Thanks!
On 27/01/2023 12.38, Peter Georg wrote:
Gentle reminder that the second question below has not been addressed yet. Any thoughts? Thanks for taking your time.
On 15/12/2022 00.04, Peter Georg wrote:
Dear all,
<snip> > > 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.
Are you asking to create and ship this package in the RHEL repos directly?
No. I'm asking to be allowed to build a centos-release-extras package in to-be-created build targets (extras8-extras-common-el8 and extras9-extras-common-el9) on CBS. RHEL users would still be required to manually download this package similar to how they install EPEL.
Peter
josh
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Wed, Apr 5, 2023 at 12:38 PM Peter Georg peter.georg@physik.uni-regensburg.de wrote:
On 05/04/2023 17.29, Josh Boyer wrote:
On Wed, Apr 5, 2023 at 6:07 AM Peter Georg peter.georg@physik.uni-regensburg.de wrote:
On 04/04/2023 13.58, Fabian Arrotin wrote:
On 03/04/2023 19:03, Peter Georg wrote:
(Second) gentle reminder that the second question below has not been addressed yet. Any thoughts? Thanks for taking your time!
It'd also be helpful if anybody can provide any information on who I need to ping to get a decision on that matter. Thanks!
On 27/01/2023 12.38, Peter Georg wrote:
Gentle reminder that the second question below has not been addressed yet. Any thoughts? Thanks for taking your time.
On 15/12/2022 00.04, Peter Georg wrote: > Dear all, >
<snip> > > 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.
Are you asking to create and ship this package in the RHEL repos directly?
No. I'm asking to be allowed to build a centos-release-extras package in to-be-created build targets (extras8-extras-common-el8 and extras9-extras-common-el9) on CBS. RHEL users would still be required to manually download this package similar to how they install EPEL.
OK, thank you for the clarification. That's what I had interpreted but there was some confusion on the request so it's good to have clarity.
josh
Another gentle reminder that the second question below has not been addressed yet.
I'd like to add that by now other SIGs also started building packages for RHEL in addition to Stream. While Fabian Arrotin mentioned a viable alternative by building centos-release-* packages in SIG specific tags, I'd prefer the CentOS project to provide an extra tag just for these (as already done for Stream) for every supported RHEL version. Having each SIG building centos-release-* packages in their own tags adds unnecessary complexity to users as they'd have to check the installation instructions of each SIG. Having a common tag would also allow us to better promote all SIGs as an integral part of the CentOS project.
On 03/04/2023 19.03, Peter Georg wrote:
(Second) gentle reminder that the second question below has not been addressed yet. Any thoughts? Thanks for taking your time!
It'd also be helpful if anybody can provide any information on who I need to ping to get a decision on that matter. Thanks!
On 27/01/2023 12.38, Peter Georg wrote:
Gentle reminder that the second question below has not been addressed yet. Any thoughts? Thanks for taking your time.
On 15/12/2022 00.04, Peter Georg wrote:
Dear all,
<snip> > > 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
CentOS-devel mailing list CentOS-devel@centos.org https://lists.centos.org/mailman/listinfo/centos-devel
On Wed, Dec 14, 2022 at 3:04 PM Peter Georg < peter.georg@physik.uni-regensburg.de> wrote:
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.
Just to clarify. The EPEL policy does not have + 30 days on it. It ends right on the EOL date. Other than that, it is correct.
Troy
-
Fabian Arrotin -
Josh Boyer -
Peter Georg -
Troy Dawson