On Tue, Oct 15, 2019 at 09:26:31PM -0400, Stephen Gallagher wrote:
Most things from the original proposal in the first message of this
thread remains the same except:
Module stream metadata would gain two new optional attributes,
"upgrades:" and "obsoletes:".
I'm sorry, but I'm against this proposal, both in its first form, and
as amended here. The long discussion in this thread has pushed me over
into conviction that modules should not be "on by default" in any way
The first form of the proposal was already staggeringly complex —
"default", "dep_enabled", "default_enabled",
"default", …. Recording
user intent when the users interacts directly with the thing
might be OK, but mapping that intent onto dependencies that are pulled
in automatically is not something that can be well defined. My expectation
is that we'd forever be fighting broken expectations and unexpected cases.
But the amended proposal actually makes things *worse*, even more complex.
We would have two parallel sets of dependency specifications: on the
rpms level and on the module level. The interactions between them would
be hard to understand for users.
I also don't think we need this at all: everything that could be
expressed using deps between modules can also be expressed using deps
between rpms. We have a rich and well defined dependency language for
rpms, so let's just use it.
One of the operational problems with Modularity is that it places huge
expectations on dnf. Modularity was never very well defined, and dnf
had to adapt on the fly to changing rules and requirements. This never
went well. Even more complexity, with three parallel sets of
semi-interacting-semi-independent sets of constraint rules (rpm deps,
module intent, module obsoletes+provides), expressed in different form,
is imho a recipe for bad ux.
At the same time, this thread has shown that this additional
complexity would need to be added to have upgrade paths for modules.
Essentially, to me this thread has shown that Modularity needs to go
back to drawing board, to reassess goals and assumptions and
implementation choices. A lot of what people *thought* Modularity
would give them, is simply not possible, and at the same time, the
costs and impact on the rest of the distribution is higher than
As has been extensively discussed, modules are opaque and a) by design
make some rpms not visible and not as available to other packagers as
before, b) make it harder for people outside of Fedora to reuse our
packaging and build on top of Fedora.
Modules also raise the complexity of packaging. I understand that for
some expert packagers they provide new functionality, but they complicate
life for the majority of packagers. I think this additional complexity
is of the reasons for the decline in participation of non-expert
packagers in Fedora that was show in FPL's graphs.
The work that went into Modularity is certainly not all wasted: I think
we all understand the problem and what solutions don't work much better
then before. I think we should take a step back and try for a solution
which has lower end-user complexity and better backwards compatibility.
I'm not asking for an improved proposal here: for me, Modularity in its
current form is simply not a net benefit for Fedora's packagers or users.
Thus, I'm against both default modules, and adding modules in the
buildroot, and against rebasing any part of Fedora to build on top of
modules. This is "contingency mode", i.e. thinking how to bring things
back to working state. I think it is OK to allow modules to be available,
but they must be opt-in, and normal rpms may not allow on the
modularized rpms in any way.
I wrote this in reply to this thread, even though some things might
fit more in the sister thread "Fedora 32 System-Wide Change proposal:
Modules in Non-Modular Buildroot". I don't want to send two mails with
a lot of text, and the two things are inextricably linked: we cannot
enable modules by default, or make more things depend on them by
including in the build root, without having working upgrade paths.