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.
> 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.
> 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.
> 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? 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?
> 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.
Kevin Kofler
_______________________________________________
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
