On Tue, Nov 5, 2019 at 3:22 PM Stephen Gallagher <sgallagh(a)redhat.com> wrote:
Last week, I put out a blog post and fedora-devel thread describing
the problems that we wanted to solve with Modularity. That thread was
not ultimately as successful as I had hoped.
My intention was to provide some scope to the problem, because it
seemed that a lot of alternatives being floated were not seeing some
of the more subtle cases that we were trying to address. However, the
biggest problem is that nearly every email to the list has been
started with a "Begging the Question" Fallacy. People have started
from the premise that "Modularity is Bad" and all of the rest of the
conversation has continued from there. I'd like to provide an
opportunity for us as a community to *constructively* state our
grievances with Modularity. The fundamental root cause of some of the
miscommunication is, I believe, that Modularity has problems and that
people have assumed that they are fundamental and unfixable.
I'd like to gather a constructive list of the actual use-cases that
you feel Modularity is causing problems for, with the following
stipulations: Any *subjective* problems will be ignored. "I think
writing YAML is harder than writing a spec file" is an example of a
subjective opinion. Similarly, "change inevitably results in some
learning curve" is a basic maxim of innovation and is not in and of
itself an argument not to change. "Modularity requires me to write
both a spec file and a YAML file, thereby increasing the total work"
is an *objective* observation (and a valid one; I'm going to include
it below in my own starter list). If you aren't sure if it's
objective, a useful question is "is it quantitatively measurable?"
(AKA "Can I assign a number to it and see that number increase or
decrease when changing something about the implementation?")
So, in the interest of highlighting some specific cases where the
current, deployed[1] implementation (in no particular order):
<snip because long list...>
This list is fairly comprehensive, but one thing I think was missed is
that we lack a policy and mechanism for making buildroot-only packages
externally consumable.
For example, the Rust modules in Fedora 30 actually have a
buildroot-only backport of RPM 4.15 to use generated build
dependencies (which is likely to be something to disallow by policy
for other reasons...), meaning that the modules are published with
SRPMs that literally will not work on Fedora 30. There is no mechanism
to consume buildroot-only packages for package builds on those modules
and so on... There's no policy that defines what cases BR-only
packages even make sense (I would argue that they don't for Fedora).
But in cases like this, we need a way for those packages to be
available when building on top of those modules or rebuilding them.
--
真実はいつも一つ!/ Always, there's only one truth!