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).
Kevin Kofler
_______________________________________________
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
