On Wed, 7 Sept 2022 at 10:04, Petr Pisar <ppi...@redhat.com> wrote: > V Wed, Aug 31, 2022 at 05:08:59PM -0400, Stephen Smoogen napsal(a): > > 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. > > 3. Archiving of the modules on XYZ date to > > /pub/archive/epel/8.YYYY-MM/Modular and pointing mirrormanager to that > for > > that > > 4. Make changes in bodhi to turn off reporting about modules for EL8. > > 5. Make changes in MBS configs to turn off building modules for EL8. > > 6. Make changes in PDC for EL8 modules > > 7. Make changes in compose scripts and tools to no longer cover EPEL-8 > > modules > > 8. Remove epel-8 modules from /pub/epel/8 > > 9. Announce closure of this proposal and any lessons learned. > > > I heard a concern what to do with systems which use EPEL modules. What will > happen after the modules disappear from EPEL repositories? > > Thanks to fails-safe machanism in DNF, the metadata for enabled module > streams > will be preserved in DNF's local copy. Thus users who have installed the > modules will have them visible in "dnf module list" output even after > removing > them from EPEL repository. So far good. > > Someone proposed that EPEL should actively try to disable the EPEL modules. > Miro mentioned that the Fedora already did it once > < > https://src.fedoraproject.org/rpms/fedora-release/c/bfc4c31d8f625d4963a8169c9ba65686da7a4ce0?branch=f31 > > > by editing DNF configuration from an RPM scriptlet. > > Question is whether EPEL should do it. If EPEL did it, users would lose > their > modules and, I think, DNF would start mixing modular and nonmodular > packages. > That could cause problems when upgading those systems. One would need to > perform "dnf distrosync --allowerasing" to repair the system. > > There could also be a problem if RHEL decided to deliver a module stream > with > an identical name. EPEL would then keep disabling the RHEL module. > > I believe it's safer not to actively disable the streams on user's systems. > > I agree on this and would not want that to happen. The module metadata needs to stay there
> What we could do is write a notice about the end of life into the module > summaries and rebuild the modules. That way users running "dnf module list" > could see the message. But people upgrading after the module removal > wouldn't > see anything. We would have keep to modular repository available forever. > Probably the idea of the notice is not worth of it. > > Any opinions how to deal with obsoleting the installed modules? > What currently does EPEL when a maintainer decides to drop a (nonmodular) > package? > > It disappears from the mirrors but a user could grab it from koji or if it was 'archived' in the /pub/archive snapshots which are done around the time a . is released. Most of the modules would still be there in the /pub/archive snapshot and a final version would be there also as step 3. > -- Petr > _______________________________________________ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to epel-devel-le...@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.org > 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
_______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@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.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
