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
Purkyňova 115
612 45 Brno - Královo Pole
_______________________________________________ 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
