On 2019-11-15, John M. Harris Jr <johnmh@xxxxxxxxxxxxx> wrote: > On Friday, November 15, 2019 6:32:21 AM MST Petr Pisar wrote: >> Example: I have Perl 5.26 as a default version. I have Perl 5.30 as an >> laternative version. Now I want to package Bugzilla that's written in >> Perl. How do you package Bugzilla so that it works with Perl 5.26 as >> well as with Perl 5.30? > > This sounds like a bug in Modularity. > Modularity can achieve it when both Perls are packaged as a module. I'm only showing why we need default stream if we want modules. >> If each of the Perls is a stream of a module, you will put Bugzilla into >> a module and let it depend on any of the Perls. User can install any of >> the Perls and Bugzilla. > > I'm guessing that Perl from a module doesn't meet a Require on perl? It meets the RPM-level "Require on perl". But that's not sufficient because every Perl version is not binary compatible. You need to track against what Perl Bugzilla was built. That means you need to build Bugzilla twice and keep these two Bugzilla builds distinct so that DNF can install the right build depending on Perl user has already installed. Modularity supports it, but you need both Perl as a module. >> 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. > > I don't believe that's the case. The packager would choose how they want to > handle it, most likely just not bothering with modules. The user would just > `dnf install bugzilla`, and use the version that is packaged as a non-modular > package. > If packager does not build Bugzilla for the modular Perl, then of course the user has no choice. But talk about a case when the user and the package wants to have a choice. -- 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
