On Tue, Oct 8, 2019 at 12:06 AM Kevin Kofler <kevin.kof...@chello.at> wrote: > > Matthew Miller wrote: > > A key goal of the modularity project is to allow some of the cases to be > > better addressed by allowing packagers to think in terms of upstream > > changes which affect user experience separate from the Fedora release > > cycle. The default stream for a package shouldn't be updated in disruptive > > ways in shipped releases, but a new-version stream could _also_ be > > available. And at the same time, if you upgrade to a new Fedora OS release > > but still need the old behavior and the packager is still maintaining it, > > you should be able to opt in to it. > > Sure, I fully understand the theoretical benefits to be had from Modularity > (though I still think that this is much more useful for LTS distributions > such as RHEL or CentOS than for Fedora). The issue is that it all breaks > down when modules depend on each other (and they already do), because of the > unavoidable versioning conflicts (Module A requires Module C version 1, > Module B requires Module C version 2, and only one version of Module C can > be installed) that bring us Module Hell, a.k.a., RPM Hell 2.0. And this > follows directly from the specification of the Modularity feature. And it > has already happened in practice (see the libgit2 chaos).
Modularity should have been opt-in until major bugs are ironed out, and maybe we would have realized in time that either it's great or it doesn't solve anything the problem it's addressing. Dridi _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to 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/devel@lists.fedoraproject.org
