On Tue, Oct 8, 2019 at 12:06 AM Kevin Kofler <kevin.kofler(a)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