On Wed, Nov 13, 2019 at 1:25 AM Kevin Kofler <kevin.kofler@xxxxxxxxx> wrote: > > Aleksandra Fedorova wrote: > > 1) I don't think Modularity is about being LTS and "enterprisy". > > Lifecycle differences are not the only feature Modularity provides. > > > > I see Modularity as a tool which bridges the gap between container > > world and a packaged distribution. > > > > Without modularity we have a base system with its limitations and the > > explosion of containerized solutions which currently go through their > > teen-age phase, denying the good old known practices and reinventing > > wheels in terms of packaging, sharing, deduplication of effort and > > security audit. > > This is not a property of not using modularity, but of using containers. > Generating containers from modular repositories also only partly solves > these issues. In particular, you still have to regenerate the entire > container for a security fix in any included library. > > The best approach to avoid the drawbacks of containers is not to start using > modules, but to stop using containers. :-) > > In addition, due to their non-parallel-installable nature, modules actually > push more container use, and thus more duplication, more complex security > updates, etc. So I think they actually have the opposite effect than what > you claim. > > > Modularity allows us to use packaging approaches in a more flexible > > but still controlled and maintained way. It creates building blocks > > for containerized environments. > > I think it is the way to go for Flatpacks, cloud images and other > > layered solutions to use runtimes built on top of packaged streams, > > rather than custom configurations. > > I also don't see why the containers cannot simply be built from a common > tested platform (a non-modular Fedora release) rather than from arbitrarily > mixed together streams. If your goal is sharing and deduplication of > efforts, then that should actually be the goal. Adding module streams to the > mix actually goes the opposite way. Deduplication plays against flexibility, with fully packaged system on one side and completely custom containerized environment on the other. In my understanding, from the point of Fedora user adding module streams is a small step towards being flexible(and therefore harder to manage). From the point of view of containers it is a giant leap towards deduplication, updates, security and all other nice things which make container lifecycle so much easier. > > And I think it is in scope of Fedora to drive this process to > > normalize the currently chaotic container world. > > I think Fedora would be better off avoiding the container world altogether. > It is a horribly inefficient way to deliver software compared to RPM > packages. I think we have to just disagree on that. I believe that "containers are Linux", they have their uses and their users, and we shouldn't be fighting against containerization, rather should explain the benefits of packaged components as they can be used in containers as well. > > 2) I don't think Modularity is a failure in its current state. > > > > Yes, we do have a problem of default streams. There are several > > reasons for that. > > > > One thing i find interesting is that: we were very cautious on tech > > implementation side, delaying certain technical tools and solutions, > > while we were not cautious enough on the process and policy. > > And it feels like we should have done it the opposite way: iterate > > (and sometimes fail) on the tooling faster, but have a much more > > restrictive approach to the policy. > > Well yes, allowing people to abuse stable Fedora releases as a place on > which to experiment with modules was a huge mistake. Those experiments > should have been done in an optional opt-in repository. (And I would even > argue that modules should always remain optional and opt-in, but in their > current state, that is most definitely the case.) > > > And now we are trying to evaluate Modularity without actually giving > > it a chance to be implemented _for real_. > > That is the part I disagree with. Already too much was implemented in > production releases. We are seeing exactly the failure modes that I had > already warned about right after reading the design documents. To clarify, the current state of things: 1) there are exactly 6 default streams in Fedora rawhide dwm avocado scala ant gimp maven and eclipse is being discussed. 2) we don't add new default modules; 3) we allowed tooling (Ursa Prime) which adds modular packages in Fedora buildroot; 4) we allowed exactly two modules to be added in Fedora buildroot via Ursa Prime: dwm and avocado; 5) the upgrade issue for modules is set to be a Beta Blocker. > > Anyway, default streams is just one side of a story. It did get into > > the critical path of Fedora and did create upgrade problems and > > certain UX issues, but I think we can restrict and resolve it. > > And what is wrong with the obvious solution, which is to just not use > default streams at all? The "obvious solution" does not solve anything for the Java stack in Fedora and four Java modules currently having default stream. > Why can the default version not be shipped in the > tried and true non-modular way, so that people who do not need or want > modules are not forced to use them against their will? This is a question to package maintainers who want to enable the default stream. But by using your "will" as an argument against their "will" we are not going anywhere in this conversation. > > For that we need to focus on the issue, which is, from my point of > > view: default streams and their differences from the ursine packages. > > > > One is caused by the lack of Ursa Prime, another is the upgrade > > functionality, > > And both are complex technical mechanisms, which will certainly come with > their own bugs and drawbacks, all just to emulate a world without default > streams while shipping default streams. I see no practical benefits > whatsoever of that approach over the straightforward KISS approach of just > not using default streams anymore. > > > and I guess the third one is the non-api and filtered packages in the > > module. > > That one is something that just needs to be banned in Fedora altogether. -- Aleksandra Fedorova bookwar _______________________________________________ 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
