Le samedi 16 novembre 2019 à 09:35 +0100, Lukas Ruzicka a écrit : > > > > Either the strategy should be: > > > > "We offer alternate Perl versions for containers etc. they conflict > > with the > > default Perl version and with the non-modular apps. That is known > > and accepted." That won't work. You *can* ship modular components as alternatives You *can* *not* ship modular components that directly compete with non- modular as defaults, because the maintainer of non modular will have made the effort to integrate with the rest of the distro, and not only the maintainer of the modular content won't have made this effort, but he will offload the integration problems *he* created to the maintainer of the default non modular version The root reason of the current mess is that modular was allowed to override things without owning the problems that created. Modular should *not* override anything by default in dep resolution. Dep resolution *may* use modular preferences as hints, but those hints should be weak at best, and be ignored by the dep resolver as soon as they conflict with dep graph resolution. And yes that means maintainers of modular things will get the rug pulled under them whenever the default stream changes in incompatible ways. Tough luck. The only reliable way we have to coordinate Fedora activity is this default stream. 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
