#198 Drop modularity from EPEL-8. Do not enable modularity for EPEL-9
Opened a month ago by smooge. Modified 2 days ago

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.

Steps:

  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 month 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.

Login to comment on this ticket.

Metadata