Le jeudi 14 novembre 2019 à 13:45 -0500, Stephen Gallagher a écrit : > On Thu, Nov 14, 2019 at 1:33 PM John M. Harris Jr < > johnmh@xxxxxxxxxxxxx> wrote: > > On Thursday, November 14, 2019 11:15:15 AM MST Stephen Gallagher > > wrote: > > > I'm not sure what you're asking here. I thought it was pretty > > > clear > > > from the paragraph you quoted that containers are the recommended > > > solution for doing "parallel-install" with modules. Also, the > > > relationship goes both ways; Modules provide a trusted source of > > > software to run in containers (as opposed to running an image > > > that > > > someone uploaded to a public registry). > > > > Well, containers are currently the only "supported" way to have > > parallel > > installation of any Fedora packages. In essence, we don't have a > > solution for > > parallel installation at all. If Modules are supposed to go with > > containers, > > why not tack them onto Silverblue instead of the main distro? From > > what I've > > read, it seems they would fit that usecase much better than a > > traditional > > distribution, and we wouldn't need to address the issues that come > > from > > modules overriding non-modular packages. > > > > You're assuming that parallel-install is a thing that everyone needs > from every package on their system. Our research and surveys > determined that this was not in fact the case for the overwhelming > majority of real-world deployments. In any way the core problem is not parallel install (I completely agree parallel install is a marginal case), or building multiple versions of the same thing (that has been possible to do in rpm since forever). The problem is *selecting* the correct version, for build, install or update, once several are available, and maintaining a working conflict- less dependency graph. So, my own conclusion from the past years of module experiments, is that something that wanted to achieve the original objectives of modules, would need to invest heavily in dependency graph analysis, instead of trying to create separate module objects we have no clue on how to manage sanely. The module layer has not made any natural self-evident way to handle competing version streams appear. On the contrary, the segregation in module silos makes it harder to identify, diagnose and heal conflicts. If someone manages to define a working solver and a working conflict resolution strategy, I'm more and more certain that the changes needed in packages themselves, to provide the additionnal info required by this solver, will turn out to be minimal. Without a working solver multiple version streams won’t work out, upstream has not more clue (and quite often a lot less clue) on what the dep graph should be, that’s why it constantly creates piles of bundled unmaintainable and unmaintained code, and handwaves the maintainership problem to someone else. Regards, -- Nicolas Mailhot _______________________________________________ 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
