> Am 10.05.2023 um 18:45 schrieb Kevin Fenzi <kevin@xxxxxxxxx>: > > On Wed, May 10, 2023 at 12:21:51PM +0800, Jens-Ulrik Petersen wrote: >> Thanks for all the helpful comments and feedback, >> though more is still welcome of course. >> So I am leaning now towards not installing fedora-repos-modular by default >> (rather than disabling the modular repos by default): also for upgrade >> compatibility. >> >> I have started a Change proposal draft, which I think should be ready soon, >> with current working title *"Turn off modular dnf repos by default"*. >> Perhaps *"No default fedora-repos-modular"* would be more precise. >> Or any better suggestions (that don't sound like modularity is being >> removed)? >> >> I think the actual work (PR's) required is not huge, >> but if someone is particularly keen to join the effort let me know. > > So, at the risk of opening a larger can of worms...and increasing the > scope here beyond what you have any desire to do... > > Should we consider just retiring modular repos entirely? > > I do know there's a number of active module builds, but I am not sure > how much users use them. While RHEL still uses modules, EPEL has retired > their epel8 modular repos. > > Can the things using modules now switch to compat packages in the main > repository? > > I realize we may want to just say 'no, not now' here, but I thought I > would bring it up. I suppose I would belong to the latter. From a Server admin’s POV the modules are a great chance to keep some backwards compatibility with our fast pacing distro. The most prominent example is PostgreSQL. It is not so rare that the new major version requires an adjustment in the application programme or at least an extensive test. And every major update also requires a migration of the entire data stock. Modularisation is a welcome opportunity to quickly switch to a new release and use new capabilities, but to carry out the adaptation / tests with PostgreSQL at your leisure. And that is just one example. Another example is changes in languages such as Ruby, where application programmes sometimes cannot keep up with the changes. Same is true for httpd or tomcat - just some other examples. If we could manage compat packages or parallel use of different major versions (as, for example, the Java runtime environment has managed to provide perfectly for decades), then modularisation would probably no longer be needed. With Fedora Server, we are not only aiming at the home lab, but also at an enterprise deployment. And there, backwards compatibility and long-term usability are an indispensable must. -- Peter Boy https://fedoraproject.org/wiki/User:Pboy PBoy@xxxxxxxxxxxxxxxxx Timezone: CET (UTC+1) / CEST /UTC+2) Fedora Server Edition Working Group member Fedora Docs team contributor and board member Java developer and enthusiast _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
