5:09 p.m.
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
[1] - https://pagure.io/epel/issue/198
10:30 a.m.
On Wed, Sep 28, 2022 at 3:09 PM Troy Dawson <tdawson(a)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
[1] - https://pagure.io/epel/issue/198
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.
2:33 a.m.
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
4:53 a.m.
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.fedorap...
I agree this should be said there.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
7:54 a.m.
On Fri, 7 Oct 2022 at 05:59, Miro Hrončok <mhroncok(a)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.fedorap...
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.
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
8:20 a.m.
On Fri, Oct 7, 2022 at 5:54 AM Stephen Smoogen <ssmoogen(a)redhat.com> wrote:
On Fri, 7 Oct 2022 at 05:59, Miro Hrončok <mhroncok(a)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.fedorap...
>
> 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
7:56 a.m.
On Fri, 7 Oct 2022 at 03:34, Petr Pisar <ppisar(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to epel-devel-leave(a)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.fedoraproj...
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren
9:35 a.m.
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(a)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
12:54 p.m.
On Fri, Oct 7, 2022 at 10:54 AM Petr Pisar <ppisar(a)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(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to epel-devel-leave(a)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.fedoraproj...
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
--
Carl George
2:03 a.m.
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/c26...;.
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
3:37 p.m.
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(a)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
[1] - https://pagure.io/epel/issue/198
560
days inactive
576
days old
epel-devel@lists.fedoraproject.org
10 comments
5 participants
participants (5)
-
Carl George -
Miro Hrončok -
Petr Pisar -
Stephen Smoogen -
Troy Dawson