On Fri, Oct 11, 2019 at 6:57 AM Simo Sorce <simo@xxxxxxxxxx> wrote: > > On Fri, 2019-10-11 at 09:56 +0200, Daniel Mach wrote: > > On 10/7/19 8:55 PM, Simo Sorce wrote: > > > I have to ask, > > > given containers are so popular and can deal with any dependency > > > without conflicting with system installed binaries, should we really > > > continue with this very complicated modular design ? > > > > There are only few people who fully understand how modularity works > > today (contyk who designed modulemd, jmracek and me who implemented the > > DNF part and few others). I agree that the modular design should be > > simplified. If we don't lower the bar, the complexity might prevent from > > wider adoption. > > Yes, at the moment it is a too complex system. Do you gain something out of that complexity that's worth it? Or is that an open question? And is it a design requirement? > > > As a former release engineer, I'm personally unhappy about lack of > > upgrade paths between module contexts and I believe that fixing this > > part of modularity design could lead to desired simplification. > > Unfortunately based on discussion I had with contyk yesterday, I don't > > believe it's achievable without making *huge* changes in the modularity > > design and the build infrastructure/process. > > Well, the way I see it, if it is not usable we shouldn't inflict it on > users unless there is a clear and overwhelming technical advantage in > doing it. So far it eludes me what advantage modularity gives that is > so important. As a contrarian, I'd be suspicious if there's complete agreement on any new thing. Do you disagree with the stated advantages of modularity? Or do you not understand the advantages of modularity? Do you think modularity is a solution in search of a problem? i.e. you don't even agree or understand the stated problem modularity is intended to solve, even before the questions of whether modularity adequately addresses the problem(s)? > > > > Shouldn't we go back to have default packages and then defer to > > > "containers" for applications (and their dependencies) that need to > > > deviate from system defaults for any reason ? > > > > I don't think containers can replace modularity. They need to coexist. > > If we want to create containers built on top of a distribution (no > > randomly picked bits from the internet, reproducible builds, security, > > ...), we need a way to distribute multiple versions of the software > > (module streams) and they frequently need to be built against each other > > (module contexts). > > If modules were just an infrastructure artifact used to build > containers (or spins, or any other useful delivery mechanism) I > wouldn't be concerned, as then the people exposed to their complexity > would be people that know what they are doing and can decide to buy in > or not into the modules ecosystem. I rather like the idea of them in flatpaks, where any problems are limited to a particular flatpak, and can't affect the local system. > My main gripe is the current situation where users are thrown under the > bus and then we give them a business card and say: read these > instruction to figure out how to save yourself. > I think this is unacceptable. Ordinary every day user or do you mean packagers being thrown under the bus. And really then, is there a difference because neither the mortal user or immortal packager should be thrown under the bus, when we get right down to it. That's certainly not a design tolerance. Too much trust in dnf has been built up for that to happen. It's natural and necessary any possibility of that be resisted. And I don't actually know any of the parameters under discussion. I don't even understand RPM let alone modularity. Every time I approach packaging I find too many barriers to entry, or at least something else that seems more interesting. I'm quite content with dnf and packagers doing the work. Is there a shrinking packager problem? -- Chris Murphy _______________________________________________ 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
