Petr Pisar wrote:
> With your proposal Bugzilla packager would have to package Bugzilla
> twice: as a normal package for default Perl 5.26 and as a module for Perl
> 5.30. Then a user would have hard time to select the right combinations of
> Perl and Bugzilla. It would double fork work pacakgers and and make
> the system more dificult for users.
The Bugzilla rebuild for the non-default Perl actually belongs IN the Perl
module. Otherwise, enabling the non-default stream for the Perl module will
break the user's Bugzilla and force them to manually enable the
corresponding non-default stream for the Bugzilla module. Plus, since there
are many Perl applications, having a module for each of them (each tracking
Perl's module streams) just does not scale.
But what this example really shows is that it is a horrible idea to have a
Perl module to begin with. The non-default Perl needs to be packaged as a
parallel-installable compatibility package (or as an SCL, but that opens its
own can of worms) instead. You cannot just replace a language interpreter
(especially not one as widely used as Perl) with a different version. (As
you pointed out yourself, that breaks even fedpkg. Even though fedpkg itself
is not even written in Perl!) The parallel-installable approach is also the
only reasonable way to support applications that require a non-default
version of Perl, without conflicting with the rest of the distribution.
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
