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