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