On 2019-11-16, Kevin Kofler <kevin.kofler@xxxxxxxxx> wrote: > 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. > Adding Bugzilla in Perl module does not scale either. You have many Perl applications and you should put them all into the Perl module. As a result you would have a Perl module containing all Perl applications. We now more than 3000 such packages. You can imagine that you were never be eable to build such a giant module because there is always a package that fails to build. Also whenever you want to provide a new incompatible application you would have to fork the giant Perl module. Do you want to have perl:5.30-with-Bugzilla-5.1.2-with-slic3r-1.3.0-...? I believe that better approach is to meld modularity into RPM. So that you can have plenty of small independent packages aware of parallel availability. > 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. > That's nice theory that will never come true becaue it would require to make all Perl code parallel-installable. And Perl code is not only libraries as in the Python language. That's also myriad of Perl scripts that you want to have in PATH. If you start fidling with things in PATH, you have the problem of SCL. And as you wrote, SCL is terrible. And that was the reason why we have modularity: We do not want to relocate code to non-standard paths. I think it's inevitable that there will be conflicts and it's better to have them managable with a package manager (i.e. having default streams) rather crates few modules that silently overlay non-modular packages whe a user enables them. The parallel installablity is nice, but it's way more difficult than parallel availability. -- Petr _______________________________________________ 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
