On 2019-11-15, John M. Harris Jr <johnmh(a)splentity.com> 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
> 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
> 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
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.