On Wed, Oct 16, 2019 at 12:11 PM Adam Williamson
On Tue, 2019-10-15 at 12:25 -0400, Neal Gompa wrote:
> > So: I'm on board with most of what you say here, but there's no need
> > say it means Modularity is "a failure". It means right now it's
> > entirely baked and we're realizing the concept needs extending and
> > perhaps reworking a bit, just like we realized with the *first* cut at
> > Modularity which we abandoned between a Beta release and a Final
> > release. This is causing us to have to deal with some icky problems,
> > but again, that's not *new*. We had to deal with some fairly icky
> > problems when systemd showed up. We had to deal with some fairly icky
> > problems when grub2 showed up. It's a process we've dealt with before.
> > We know how to do it. We just need to hold our noses and fix the icky
> > problems, and then sit down and think about the design issues that have
> > become apparent in Modularity v2 through our actually implementing it
> > and using it (which is what Fedora is for, remember!) and figure out
> > how to address them in Modularity v3.
> Are we going to do a Modularity v3? Because people seemed to be
> *really* reluctant to go down that path because it would break
> compatibility with RHEL.
Well, those are just the terms I use to think about it, they have no
official validity. So in a sense it's a pointless semantic question.
Let's put it this way: I'd be surprised if we don't wind up having to
make significant changes/enhancements to the modularity rules and/or
implementation to be able to resolve the issues we're dealing with
right now (Stephen, in some of his replies, seems to agree) and to me
it'd be valid to call that 'modularity v3'. Whether anyone else would
call it that or not doesn't seem too important :)
I agree with everything Adam just said. I'd avoid the term "Modularity
v3" in general, because it sounds like a total redesign (which is what
the v1->v2 switch ended up being). So far, all of the things I've been
proposing have been done with an aim of not causing any additional
breakage and to ensure that an upgrade path exists.
That said, as we've rolled this out, new information has come up that
is requiring us to re-evaluate some of the original design decisions
(the most obvious being the "changing default streams" case). The two
different proposals for how to handle that have been offered up
because they provide an upgrade path to get out of the current
situation without significant manual intervention.
Also, I want to reiterate this point, because it is central: There are
three core issues from which most of the complaints in this thread
1) Modular default streams are not available to the non-modular
buildroot, so packages that want to build against them are forced to
either become modules or vanish from Fedora (or use complex build-time
2) Once a stream has been enabled on the system, users are bound to it
- even across upgrades between releases. Since the purpose of default
streams is to eliminate the need for users to understand module
interactions if they want to continue operating the way they did
pre-Modularity, they need to be able to follow stream changes on
upgrades to match the intended defaults for the new system.
3) The policy on default streams was not clearly defined and
communicated. The Modularity WG recently voted to affirm that all
artifacts installable from default streams of a module must obey all
of the rules of packages in non-modular Fedora (primarily Stable
Updates policy and the expectation that they are treated as supported
API for all purposes). This is the "Java/Maven Problem", where the
Java team created a maven module that included stripped-down
dependencies in the default stream, thus owning those package names
with unsupported content.
We have plans in place for how to deal with each of these critical
problems (without resorting to throwing it all away).
1) This will be solved by the new Koji/MBS feature that we've
codenamed "Ursa Prime" (as a replacement for the original "Ursa
tool that was built for RHEL 8). Unlike its predecessor, it requires
no additional daemon service running to handle things. We will create
a buildroot compose for each release that is created from the set of
packages available from all of the default streams and both Koji (in
infra) and mock (on packager systems) will be able to consume this.
Koji will behave the same as mock, where it will rely on libdnf's
default module stream handling to populate the buildroot, so we won't
have to worry about disparities between the local and infrastructure
2) There is an entire email thread  dedicated to how we are going
to solve this. I won't repeat it here.
3) We need to get the policy I described above written onto -stone
tablets- the Packaging Guidelines and then we need to go and make any
stream that isn't compliant with it a non-default stream.