On Fri, Oct 11, 2019 at 8:50 AM Stephen Gallagher <sgallagh(a)redhat.com> wrote:
On Thu, Oct 10, 2019 at 10:41 AM Lukas Ruzicka <lruzicka(a)redhat.com> wrote:
> Seeing the reaction of the Modularity WG ... I do not understand how it is possible
that such important decisions are taken by 4 people without any Fedora wide discussions
like this. And yet, it seems a little bit that even opinions on this list will not fall on
To be clear, I am reading every single reply to this thread very carefully. We *will* be
taking all of this feedback into consideration, but please understand that we're also
trying to balance things. As Neal noted upthread, we do have a responsibility to our
downstream to make sure that we do not break the ability to manage default streams. This
becomes much more difficult if we cannot have them in Fedora, because the testing of them
is lost. Additionally, no one on the WG disagrees with you that the current state of
things is undesirable. I take a moderate amount of offense to the repeated insinuations
that the solutions we are building are "hacks". Yes, there's a proposal to
work around the upgrade issue to F31 that is absolutely a one-off hack to buy time. But
our plans for how upgrades should work long-term as well as how defaults need to behave in
the distro are being considered very carefully. We are trying to avoid breakage and to
make the process simpler, but we are also shoring up the bridge while crossing it.
Two years into this, I am currently not confident that modularity will
be adapted to support community distributions well, especially
fast-paced ones like Fedora. My fears about it encouraging Fedora to
slow down has also seemingly borne fruit, too. Java is proof positive
Since the implosion of Fedora Java in the regular distribution and its
move to modules, the traditional effort to move to newer Java versions
has basically disappeared. Java 11 LTS was released last year, and to
this day our default Java is still Java 8 (which is EOL!). Clearly,
we're developing a new antipattern that we need to nip in the bud
sooner rather than later.
My disappointment in this became even greater when openSUSE beat us to
switching to Java 11. Their packaging is derived from ours! They've
demodularized Java for openSUSE and then did the work to move
everything forward. Meanwhile, we've now failed at our "first" and
"features" pillars because the incentive is now *gone*.
We are absolutely considering the option of disallowing default
streams in Fedora, but we *really* don't want to rush into that. For one thing, we do
have a number of packages that have moved to modules-only that would have to convert back.
For some projects, this is probably just an annoyance, but for others this may be a major
impediment. In particular, one of the advantages of Modularity is the ability to have
buildroot-only packages that are different from the base operating system (and don't
end up delivered as artifacts from the module). There are likely modules out there that
rely on this behavior because their build requires a newer or older version of some
package than the non-modular buildroot provides. This is not the sole problem to address
if we go the "no defaults" route, just the first that came to mind. It's
unclear to me right now if forcing everyone back to the old behavior is less effort than
fixing the remaining Modularity issues. And since we need to fix them for RHEL as well
anyway, it's worth considering carefully if the added work is worthwhile.
The buildroot-only packages thing should have been banned in Fedora.
In my view, this feature is very much an anti-community feature,
because it heavily discourages shared maintainership and permits even
more orphanings than should be allowed. The more we do this, the less
value the distribution itself actually provides.
For example, it's pretty painful to package Rust software because you
cannot rely on the existence of Rust components in the distribution.
Everything *must* get built and integrated for each package. This not
only defeats one of the major virtuous outcomes of Fedora
participating in ecosystems (maintainers helping upstreams keep their
software fresh and secure), but also makes it functionally impossible
to distribute the workload of maintaining Rust packages in the same
way we have for Python, C/C++, and Perl.
I'm wary of assuming that this thread represents the whole of
Fedoran opinions, however. As we all know, it's generally the set of people who are
upset that speak up the loudest. I'm not discounting your concerns (far from it!), but
if we only base development decisions on "make sure no one is upset about it",
we'd never accomplish anything new at all. This is why when I've been sending out
these emails to discuss ideas, I've been trying to carefully describe both the
use-cases and the technical limitations (both intrinsic to the design and those that are
the result of imperfect implementation) each time. It's somewhat disheartening to hear
responses that largely boil down to "If you can't get it perfectly right, stop
At least this Fedora packager is getting super burned out with the
number of problems caused in his day to day by the creation of
module-only software in Fedora. I've never really had a problem with
the idea of modules for alternative software, but I deeply despise the
dependency on modularity for "default" software (per modularity
I still don't have a good grasp of what to do anymore for packaging.
I've edged away from packaging anything that involves modularity in
Fedora proper because it's just too complex for me to grok.
And as a third party packager, I really don't want to deal with
modules for "default distro" setups. How am I supposed to make my
software compatible with all of the potential module filters imposed
on me by DNF? I don't know how to deal with depending on content
existing in default modules either...
真実はいつも一つ！/ Always, there's only one truth!