Re: disabling yum modular repos by default?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, May 10, 2023 at 07:09:49PM +0200, Peter Boy wrote:


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.

Debian has parallel installation with PostgreSQL. It does mean the major versions show up in the DB paths, but I don't think that's a bad thing. I think various problems that modularity tries to solve could also be solved with parallel installs and sometimes provide a better user experience.
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux