When EPEL-8 was launched, it came with some support for modules with the hope that a module ecosystem could be built from Fedora packages using RHEL modules as an underlying tool. This has never happened and we have ended up with a muddle of modular packages which will 'build' but may not install or even run on an EL-8 system. Attempts to fix this and work within how EPEL is normally built have been tried for several years by different people but have not worked.
At this point we are saying that this experiment with modules in EPEL has not worked and we will focus our resources on what does work.
Schedule of EPEL 8 Module Retirement: Next Week: - epel-release will be updated. -- epel-modular will set enabled = 0 -- epel-modular full name will have "Deprecated" in it
October 31 2022: - The EPEL 8 modules will be archived and removed. -- The mirror manager will be pointed to the archive. - Packagers will no longer be able to build EPEL 8 modules.
After October 31st (Actual date to be determined): - epel-release will be updated again. -- epel-modular repo configs will be removed.
Questions and Answers:
Question: Will I still be able to access the modules after October 31st? Answer: It is not recommended, because the modules will not get any security or bug fixes, but yes. They will be in the Fedora archives, and the mirror managers will point at them.
Question: What will you be dressed as on Halloween? Answer (Troy): A Penguin
EPEL Steering Committee
On Wed, Sep 28, 2022 at 3:09 PM Troy Dawson tdawson@redhat.com wrote:
When EPEL-8 was launched, it came with some support for modules with the hope that a module ecosystem could be built from Fedora packages using RHEL modules as an underlying tool. This has never happened and we have ended up with a muddle of modular packages which will 'build' but may not install or even run on an EL-8 system. Attempts to fix this and work within how EPEL is normally built have been tried for several years by different people but have not worked.
At this point we are saying that this experiment with modules in EPEL has not worked and we will focus our resources on what does work.
Schedule of EPEL 8 Module Retirement: Next Week:
- epel-release will be updated.
-- epel-modular will set enabled = 0 -- epel-modular full name will have "Deprecated" in it
October 31 2022:
- The EPEL 8 modules will be archived and removed.
-- The mirror manager will be pointed to the archive.
- Packagers will no longer be able to build EPEL 8 modules.
After October 31st (Actual date to be determined):
- epel-release will be updated again.
-- epel-modular repo configs will be removed.
Questions and Answers:
Question: Will I still be able to access the modules after October 31st? Answer: It is not recommended, because the modules will not get any security or bug fixes, but yes. They will be in the Fedora archives, and the mirror managers will point at them.
Question: What will you be dressed as on Halloween? Answer (Troy): A Penguin
EPEL Steering Committee
Question: Many Enterprise customers need time for a transition like this. Can the transition date be pushed back? Answer: This will have to be voted on by the EPEL Steering Committee. The answer is likely yes, but I won't give a firm answer until it's been discussed and voted on.
V Wed, Sep 28, 2022 at 03:09:32PM -0700, Troy Dawson napsal(a):
- epel-release will be updated.
-- epel-modular will set enabled = 0
Does it only mean releasing a new epel-release package with epel-modular configuration file set to "enabled = 0", or does it also involve more magic like editing that configuration with RPM scriptlets.
I ask because configuration files edited by a user are not subject of RPM updates. rpm tool installs updated files under a new file name and keeps the original intact, effectively unupdated.
October 31 2022:
- The EPEL 8 modules will be archived and removed.
Does EPEL have any communication channel to EPEL users besides this mailing list? If it does, do you plan to announce this change there? Preferably ahead of time.
I worry that users do not follow a list called epel-devel because they think it's only for EPEL developers. As such this change will come to them as a surprise.
-- Petr
On 07. 10. 22 9:33, Petr Pisar wrote:
Does EPEL have any communication channel to EPEL users besides this mailing list? If it does, do you plan to announce this change there? Preferably ahead of time.
I worry that users do not follow a list called epel-devel because they think it's only for EPEL developers. As such this change will come to them as a surprise.
https://lists.fedoraproject.org/archives/list/epel-announce@lists.fedoraproj...
I agree this should be said there.
On Fri, 7 Oct 2022 at 05:59, Miro Hrončok mhroncok@redhat.com wrote:
On 07. 10. 22 9:33, Petr Pisar wrote:
Does EPEL have any communication channel to EPEL users besides this
mailing
list? If it does, do you plan to announce this change there? Preferably
ahead
of time.
I worry that users do not follow a list called epel-devel because they
think
it's only for EPEL developers. As such this change will come to them as a surprise.
https://lists.fedoraproject.org/archives/list/epel-announce@lists.fedoraproj...
I agree this should be said there.
mailman3 ate the emails announcing the change. I have hopefully fixed that the email announcing it was accepted.
On Fri, Oct 7, 2022 at 5:54 AM Stephen Smoogen ssmoogen@redhat.com wrote:
On Fri, 7 Oct 2022 at 05:59, Miro Hrončok mhroncok@redhat.com wrote:
On 07. 10. 22 9:33, Petr Pisar wrote:
Does EPEL have any communication channel to EPEL users besides this
mailing
list? If it does, do you plan to announce this change there? Preferably
ahead
of time.
I worry that users do not follow a list called epel-devel because they
think
it's only for EPEL developers. As such this change will come to them as a surprise.
https://lists.fedoraproject.org/archives/list/epel-announce@lists.fedoraproj...
I agree this should be said there.
mailman3 ate the emails announcing the change. I have hopefully fixed that the email announcing it was accepted.
The email finally went through. It looks like mailman3 told me it was on hold, but a filter caught that message so I didn't see it.
I am also writing an article for Fedora Magazine and Fedora Community Blog. I put those on hold when the shut off date came up for discussion https://pagure.io/epel/issue/198#comment-820252
I didn't want to write an article with the wrong dates in it.
Troy
On Fri, 7 Oct 2022 at 03:34, Petr Pisar ppisar@redhat.com wrote:
V Wed, Sep 28, 2022 at 03:09:32PM -0700, Troy Dawson napsal(a):
- epel-release will be updated.
-- epel-modular will set enabled = 0
Does it only mean releasing a new epel-release package with epel-modular configuration file set to "enabled = 0", or does it also involve more magic like editing that configuration with RPM scriptlets.
I ask because configuration files edited by a user are not subject of RPM updates. rpm tool installs updated files under a new file name and keeps the original intact, effectively unupdated.
My original thought was turning if off for new users, but I am realizing because we defined it to be on by default.. we will be breaking existing users. Thanks for questioning my logic as it was wrong.
October 31 2022:
- The EPEL 8 modules will be archived and removed.
Does EPEL have any communication channel to EPEL users besides this mailing list? If it does, do you plan to announce this change there? Preferably ahead of time.
There are 2 emailing lists. One of them ate the email that troy sent a while ago and held it versus accepting it. I have kicked the server and hopefully it gets sent now. That said we need to fix the communication and update it for better dates.
We thought of rebuilding all of the existing modules with an updated deprecated somewhere in the data, but since many of them are just branched for each release it looked like we would instead say the module was deprecated in existing Fedora releases. I expect there is a way to do this, but I have no idea what it would break.
I worry that users do not follow a list called epel-devel because they think it's only for EPEL developers. As such this change will come to them as a surprise.
There used to be an epel-users list but about 8 real people subscribed to it versus N hundred spam accounts. We turned it off after most of the posts were needing to be deleted or the few questions being asked were never being answered because the developers were not on it.
-- Petr _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
V Fri, Oct 07, 2022 at 08:56:41AM -0400, Stephen Smoogen napsal(a):
On Fri, 7 Oct 2022 at 03:34, Petr Pisar ppisar@redhat.com wrote:
V Wed, Sep 28, 2022 at 03:09:32PM -0700, Troy Dawson napsal(a):
- epel-release will be updated.
-- epel-modular will set enabled = 0
Does it only mean releasing a new epel-release package with epel-modular configuration file set to "enabled = 0", or does it also involve more magic like editing that configuration with RPM scriptlets.
I ask because configuration files edited by a user are not subject of RPM updates. rpm tool installs updated files under a new file name and keeps the original intact, effectively unupdated.
My original thought was turning if off for new users, but I am realizing because we defined it to be on by default.. we will be breaking existing users. Thanks for questioning my logic as it was wrong.
Just confirming that epel-release dist-git reads:
$ grep yum.repos.d/epel-modular.repo epel-release.spec %config(noreplace) %{_sysconfdir}/yum.repos.d/epel-modular.repo
To some extent, it won't break existing users:
Those who have never enabled any EPEL module stream will not miss the content. They will stop seeing the modules. And that's what we want.
Those who have enabled an EPEL stream because installed packages from it will stop seeing the EPEL repository. But they will still keep seeing the enabled streams because DNF backed them up at time of enablement and will present them as a "@failsafe" repository. These users will be able to inspect and reset (= unenable) the streams. Though they won't be able to install or reinstall packages from the stream because DNF does not back up the RPM packages. I think that's, to some extent, what we want.
Those who have enabled some third-party streams which depend on an EPEL stream got the EPEL stream also enabled as a dependency. Hence they will be in the same situation as users from the previous paragraph. However, if the third-party stream enrolls an update which will require installing a new package (or enabling a new EPEL stream) they will get a dependency error. This is an unfortunate situation. We only can recommend to the third-party supplier to start delivering the stream which has been removed from EPEL.
There are 2 emailing lists. One of them ate the email that troy sent a while ago and held it versus accepting it. I have kicked the server and hopefully it gets sent now. That said we need to fix the communication and update it for better dates.
Great. The announce list is a low traffic enough so that user reading Troy's message can panic at the intended level.
We thought of rebuilding all of the existing modules with an updated deprecated somewhere in the data, but since many of them are just branched for each release it looked like we would instead say the module was deprecated in existing Fedora releases. I expect there is a way to do this, but I have no idea what it would break.
Yeah. The sources are shared across all distributions. I wouldn't dare injecting builds for EPEL8 only. MBS has its own pecularities as it concerns expanding existing streams resolving the latest module version and that could affect building depending modules in Fedora.
I worry that users do not follow a list called epel-devel because they think it's only for EPEL developers. As such this change will come to them as a surprise.
There used to be an epel-users list but about 8 real people subscribed to it versus N hundred spam accounts. We turned it off after most of the posts were needing to be deleted or the few questions being asked were never being answered because the developers were not on it.
It's a pitty DNF cannot deliver news to users based an installed package.
DNF only can deliver security news based on a fixed package. And to make it worse, that feature is unreliable for modular packages because it does not transport a stream name.
-- Petr
On Fri, Oct 7, 2022 at 10:54 AM Petr Pisar ppisar@redhat.com wrote:
V Fri, Oct 07, 2022 at 08:56:41AM -0400, Stephen Smoogen napsal(a):
On Fri, 7 Oct 2022 at 03:34, Petr Pisar ppisar@redhat.com wrote:
V Wed, Sep 28, 2022 at 03:09:32PM -0700, Troy Dawson napsal(a):
- epel-release will be updated.
-- epel-modular will set enabled = 0
Does it only mean releasing a new epel-release package with epel-modular configuration file set to "enabled = 0", or does it also involve more magic like editing that configuration with RPM scriptlets.
I ask because configuration files edited by a user are not subject of RPM updates. rpm tool installs updated files under a new file name and keeps the original intact, effectively unupdated.
My original thought was turning if off for new users, but I am realizing because we defined it to be on by default.. we will be breaking existing users. Thanks for questioning my logic as it was wrong.
Just confirming that epel-release dist-git reads:
$ grep yum.repos.d/epel-modular.repo epel-release.spec %config(noreplace) %{_sysconfdir}/yum.repos.d/epel-modular.repo
To some extent, it won't break existing users:
Those who have never enabled any EPEL module stream will not miss the content. They will stop seeing the modules. And that's what we want.
Those who have enabled an EPEL stream because installed packages from it will stop seeing the EPEL repository. But they will still keep seeing the enabled streams because DNF backed them up at time of enablement and will present them as a "@failsafe" repository. These users will be able to inspect and reset (= unenable) the streams. Though they won't be able to install or reinstall packages from the stream because DNF does not back up the RPM packages. I think that's, to some extent, what we want.
One of the biggest problems with modularity in EPEL is the our current implementation doesn't allow requiring modules from another build system [0][1]. Has some other third party implementation solved this? And more importantly, do any third party modules exist that require EPEL modules?
[0] https://pagure.io/epel/issue/75 [1] https://pagure.io/fedora-infrastructure/issue/8690
Those who have enabled some third-party streams which depend on an EPEL stream got the EPEL stream also enabled as a dependency. Hence they will be in the same situation as users from the previous paragraph. However, if the third-party stream enrolls an update which will require installing a new package (or enabling a new EPEL stream) they will get a dependency error. This is an unfortunate situation. We only can recommend to the third-party supplier to start delivering the stream which has been removed from EPEL.
There are 2 emailing lists. One of them ate the email that troy sent a while ago and held it versus accepting it. I have kicked the server and hopefully it gets sent now. That said we need to fix the communication and update it for better dates.
Great. The announce list is a low traffic enough so that user reading Troy's message can panic at the intended level.
We thought of rebuilding all of the existing modules with an updated deprecated somewhere in the data, but since many of them are just branched for each release it looked like we would instead say the module was deprecated in existing Fedora releases. I expect there is a way to do this, but I have no idea what it would break.
Yeah. The sources are shared across all distributions. I wouldn't dare injecting builds for EPEL8 only. MBS has its own pecularities as it concerns expanding existing streams resolving the latest module version and that could affect building depending modules in Fedora.
I worry that users do not follow a list called epel-devel because they think it's only for EPEL developers. As such this change will come to them as a surprise.
There used to be an epel-users list but about 8 real people subscribed to it versus N hundred spam accounts. We turned it off after most of the posts were needing to be deleted or the few questions being asked were never being answered because the developers were not on it.
It's a pitty DNF cannot deliver news to users based an installed package.
DNF only can deliver security news based on a fixed package. And to make it worse, that feature is unreliable for modular packages because it does not transport a stream name.
-- Petr _______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
V Mon, Oct 10, 2022 at 12:54:44PM -0500, Carl George napsal(a):
One of the biggest problems with modularity in EPEL is the our current implementation doesn't allow requiring modules from another build system [0][1]. Has some other third party implementation solved this? And more importantly, do any third party modules exist that require EPEL modules?
I was told that there are companies which build and deploy their own modules. I have no other datails. Especially whether their modules depend on EPEL modules.
A special example are RHEL rebuilds. E.g. Oracle can reproduce RHEL modules, including dependencies, with exact name-stream-version-context-architecture string https://yum.oracle.com/repo/OracleLinux/OL8/appstream/x86_64/repodata/c26cb67fb60842991270a0a6c37b52cd356c437fcb7c4b8d540ad71fc70c4fc9-modules.yaml.gz.
However, I think this problem is of topic now. If EPEL and MBS people were able to tackle it they wouldn't call off modules from EPEL.
-- Petr
There has been a schedule update to the epel8 modularity removal.
October 31, 2022 - The updated epel-release will be pushed to epel8 stable -- This sets "enabled = 0" for epel-modular, if you haven't already changed your config.
February 15, 2023 - The EPEL 8 modules will be archived and removed. -- The mirror manager will be pointed to the archive.
* Question:Why was the final archive moved to February 15th. * Answer1: EPEL is made to help Enterprise users. Many Enterprise users are already in an end of the year freeze. This will give them time to plan, test, and implement any changes they might face. * Answer2: Because February 14th was voted down by our significant others.
EPEL Steering Committee
On Wed, Sep 28, 2022 at 3:09 PM Troy Dawson tdawson@redhat.com wrote:
When EPEL-8 was launched, it came with some support for modules with the hope that a module ecosystem could be built from Fedora packages using RHEL modules as an underlying tool. This has never happened and we have ended up with a muddle of modular packages which will 'build' but may not install or even run on an EL-8 system. Attempts to fix this and work within how EPEL is normally built have been tried for several years by different people but have not worked.
At this point we are saying that this experiment with modules in EPEL has not worked and we will focus our resources on what does work.
Schedule of EPEL 8 Module Retirement: Next Week:
- epel-release will be updated.
-- epel-modular will set enabled = 0 -- epel-modular full name will have "Deprecated" in it
October 31 2022:
- The EPEL 8 modules will be archived and removed.
-- The mirror manager will be pointed to the archive.
- Packagers will no longer be able to build EPEL 8 modules.
After October 31st (Actual date to be determined):
- epel-release will be updated again.
-- epel-modular repo configs will be removed.
Questions and Answers:
Question: Will I still be able to access the modules after October 31st? Answer: It is not recommended, because the modules will not get any security or bug fixes, but yes. They will be in the Fedora archives, and the mirror managers will point at them.
Question: What will you be dressed as on Halloween? Answer (Troy): A Penguin
EPEL Steering Committee
epel-devel@lists.fedoraproject.org
-
Carl George -
Miro Hrončok -
Petr Pisar -
Stephen Smoogen -
Troy Dawson