On Mon, Nov 18, 2019 at 6:23 AM Mikolaj Izdebski <mizdebsk@xxxxxxxxxx> wrote: > > On Thu, Nov 14, 2019 at 4:59 PM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote: > > I've asked whether it wouldn't be in fact much easier to keep the default > > versions of our packages non-modular. > > > > Others have said they are interested in this as well. A huge thread happened but > > it hasn't delivered an answer. > > Arguments were made that default modular streams are planned to deliver the > > exact same experience as non-modular packages, yet it was not said if it > > wouldn't be easier to just deliver non-modular packages for default versions. > > > > Maybe it would be helpful to try to reformulate the question: > > > > > > **What are the benefits of default modular streams over non-modular packages?** > > As Petr Pisar noted earlier, default streams are designed to deliver the same > user experience as ursine packages, therefore there is no *direct* advantage > or disadvantage of them over ursine packages, for Fedora *users*. Confusing and inconsistent resolution of dependency chains is a direct consequence of using modularity. These threads have pointed out others. > Default streams are modules. Building packages as modules has very significant > advantages to some package maintainers. Certain maintainers (like me) can save > a lot of time by building packages as modules. This *indirectly* > benefits users and Those maintainers are a small though vocal minority. Can anyone name three packages that genuinely benefit from modularity, rather than /etc/alternatives, SCL style separate deployment in /opt/. If there was always a bae installation and modules were, in fact, only an add-on, that might have been more stable. > other Fedora contributors - maintainers who can more easily build packages have > more time to spend on important bugs and features affecting users, can get more > involved in other Fedora activities etc. At the cost of the time of *other* package maintainers who have to deal with the inconsistent dependency resolutions at build and deployment time. It's not, so far, proven to be a helpful technology. _______________________________________________ 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
