#198 Drop modularity from EPEL-8. Do not enable modularity for EPEL-9
Closed: Fixed 5 months ago by tdawson. Opened a year ago by smooge.

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 it is time to say this experiment with modules in EPEL has not worked and focus resources on what does work. I would like to propose that modular support is removed from EPEL by January 2023.


  1. Approval of this proposal by the EPEL Steering committee and any other ones required.
  2. Announcement of end of life to various lists.
    2a. email module maintainers that packages will be archived and removed. Ask if they would make non-modular versions from their fedora trees.
  3. move epel-modular.repo and epel-testing-modular.repo to it's own sub-package of epel-repos-modular
  4. Archiving of the modules on XYZ date to /pub/archive/epel/8.YYYY-MM/Modular and pointing mirrormanager to that for that
  5. Make changes in bodhi to turn off reporting about modules for EL8.
  6. Make changes in MBS configs to turn off building modules for EL8.
  7. Make changes in PDC for EL8 modules
  8. Make changes in compose scripts and tools to no longer cover EPEL-8 modules
  9. Remove epel-8 modules from /pub/epel/8
  10. Drop https://src.fedoraproject.org/rpms/epel-release/blob/epel8/f/epel-testing-modular.repo from epel-repos-modular
  11. Announce closure of this proposal and any lessons learned.

Additionally, there will be no modules in EPEL-9 and work to enable them will not occur.

Tagged with "meeting" so we can start work on Step 1 at next weeks meeting.

Metadata Update from @tdawson:
- Issue tagged with: meeting

a year ago

I expect that there will also need to be more communication on fedora-devel on this but I figured that would happen after a 'first reading' of the proposal at the meeting.

While wholeheartedly supporting this action, I do have a question: what will happen to the current modular packages? Will they be rebuilt as plain rpm packages? Or just dropped?

That would be up to the maintainers of the packages. Packages in EPEL are volunteered and if the maintainer only wanted to support a module they don't have to move them over to regular. On the other hand, if they decided to drop the module (as some have) it would also go away.

In the end, the modules that were there before the 'end' would be still available in the 'archive' repository that people could aim at as needed.

+1. I'm happy to get rid of any modules I own.

I used EPEL modules to deliver a more modern version of nginx (nginx mainline, specifically) to EL8.
I don't know how many people actually ever used this and I would be okay with dropping modules from EPEL.

I fully endorse getting rid of modularity in epel8 and not enabling it in epel9... Has led to some confusing workflows...

Vote from this week EPEL Steering Committe meeting: +8 For 0 Against.

Let's do this.

We discussed this again at the EPEL Steering Committee meeting. Since the end goal is to EOL epel8-modular, not keep it around as an opt-in/opt-out, we agreed that just setting enabled=0 is a better intermediate step than moving the repo definitions to a subpackage. That has been implemented in https://src.fedoraproject.org/rpms/epel-release/pull-request/26.

I am really very sorry for my late comment but the proposal will negatively effect thousands of end users and they have not a chance to participate on the discussion. I also would like to point out that the proposal will not provide any value to end users. Is there any chance to reconsider the decision?

To be clear, I am fine with modifications for EPEL9, but I have a problem with the change for EPEL8. In Fedora such a change will be only allowed for unreleased Fedora version. Can we at least split the proposal for EPEL8 and EPEL9?

My hope is that the changes as planned would not break people worse than they are currently as the content would still be there but in a different tree. I had thought of keeping it in the current directory structure and 'frozen' but the Fedora Build System compose would have problems with that.

That said, there are several cases which have been brought up where it will cause problems and we need to deal with:

  • satellite and similar systems download modules from a URL and not a metalink.
  • there is no easy way to move from modular content to non modular via RPM commands.
  • various Enterprise sites are going into 'holiday' lockdown from around Oct 15 -> Feb 15 to deal with many holidays.

We do need to discuss this on the epel-devel list and next weeks meeting to figure out how to help.

Metadata Update from @smooge:
- Issue assigned to smooge

a year ago

I also would like to point out that the proposal will not provide any value to end users.

The value proposition is removing a repository of content that is routinely uninstallable and routinely violates policy by overlapping RHEL module streams.

Can we at least split the proposal for EPEL8 and EPEL9?

EPEL 9 Modular was already decided against in #135, separate from this initiative.

Should I interpret the results of this week's meeting to be officially Decided™ or is Oct 31 still officially the plan of record?

I'm very sorry for dropping the ball on this.
It has been officially decided.
October 31st we will push the new epel-release to stable, but we will NOT be disabling, or removing the epel8 modules until February 15th.

emails and articles are coming.

Metadata Update from @smooge:
- Assignee reset

11 months ago

Metadata Update from @smooge:
- Issue untagged with: meeting

11 months ago

This is very disappointing news. I was hoping for the php-pecl-redis package to become available in epel8 so that the vendor provided PHP packages could be used and to take advantage of the long term support.

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.

Even if the modular build is not working properly, it is not enough reason to drop the functionality, unless it breaks the non-modular software building/distribution.
The main point of the stream functionality is that you can have multiple versions of the same software. That decision is bad for the long term future of EPEL since the main OS distribution will still be stream based.

Basically the only way that 'worked' for the last multiple years is being able to use 'default' modules. However many of those modules are actually out of 'support' from Red Hat so yes it breaks non-modular software building in some cases.

I realized that our February 15th date is coming up next week. I started looking at what changes might be needed to epel-release so we could have them available in the testing repo ready to go. This item was part of the original plan:

Drop https://src.fedoraproject.org/rpms/epel-release/blob/epel8/f/epel-testing-modular.repo from epel-repos-modular

I'm assuming this was meant to include epel-modular.repo as well. But I also noticed this item in the plan:

Archiving of the modules on XYZ date to /pub/archive/epel/8.YYYY-MM/Modular and pointing mirrormanager to that for that

We already have epel-modular and epel-testing-modular disabled by default with DEPRECATED in the repo name. Once MirrorManager is updated the repo definition will still work if enabled. Do we actually want to remove the repo definitions? I could see the argument that it would be considerate to people that still want that content for us make it easy to access with just an --enablerepo epel-modular flag. However I could also see the alternate argument, that we shouldn't make the content easy to get to since it's unmaintained.

We have always kept old content reachable for fedora/epel. (ie, if you install a fedora 7, or rhel5 with epel box, the repos would point you to archives and still work)

That said, I personally don't feel strongly about the modularity content here. I suspect few people have used it.

I would say we leave it but make it clear in the repository file that the data is end of lifed and no longer updated.

I say leave them. Possibly adding to the name so that it is "UNMAINTAINED" or "ARCHIVED". Although I'm not against just leaving them as "DEPRECATED"

I was planning on doing an email and another Fedora Magazine article. And we'll need to rebase, and merge Diago's fix of the main EPEL documentation.

Metadata Update from @tdawson:
- Issue tagged with: meeting

7 months ago

Metadata Update from @carlwgeorge:
- Issue untagged with: meeting

7 months ago

All actions have been completed.
Modularity has been completely dropped from epel8

Metadata Update from @tdawson:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

5 months ago

Login to comment on this ticket.