On Tue, Oct 15, 2019 at 09:26:31PM -0400, Stephen Gallagher wrote: > Alternate Proposal: > > 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 in Fedora. 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 expected. 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. Zbyszek _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
