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." > > Or the strategy should be: > > "We build all our Perl applications for all our Perl versions, so users > who > choose their Perl stream can still keep their applications from the > distribution." > > Exactly. While I am thinking that the *first strategy is easily achievable*, even with what we already have, the *second strategy is very complicated* to achieve, because we cannot predict what applications users want to install and in which versions. They all would have to work in Fedora, otherwise the distro does not make sense any more. Let me explain.
If I know that installing an alternative version of Perl could break Perl bindings to other applications, I can create a container to use that alternative version of Perl and be happy, having actually the standard Perl in the system and another version in the container, or I just install a system with that, because I only need to have one purpose operating system, such as LAMP or other servers. That's fine. For desktop users, however, this is not good because you place limitations on them. While I believe it is fairly ok to build a server solution around containers (or even virtual machines), this is overly complicated for Desktop. I do not understand why we would like to make Desktop complicated, when the majority of Red Hat use Fedora as their desktop solution. Also, there are spins that basically are Workstations (or other desktops) that have certain packages pre-installed and we expect them to work flawlessly. The questions is: *With modularity ... can we make sure that everything works with everything as it does nowadays?* I believe that having non-modular defaults will make sure the distro works in its entirety, while having alternative versions in modules will help developers and sysadmins to install what they want and need, if it is not the default. For me, this is a win win situation. I understand that it is more work for the packager, but it is more convenient for the users and we should think about the users in the first place. I have been following this discussion since it started and all I am getting is "We are having issues, but we are working on them.", but nobody has ever explained why it is bad to use Miro's approach. -- Lukáš Růžička FEDORA QE, RHCE Red Hat <https://www.redhat.com> Purkyňova 115 612 45 Brno - Královo Pole lruzi...@redhat.com TRIED AND PERSONALLY TESTED, ERGO TRUSTED. <https://redhat.com/trusted>
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
