On 2019-11-15, Daniel P Berrangé <berrange@xxxxxxxxxx> wrote:
> On Fri, Nov 15, 2019 at 02:53:08PM -0000, Petr Pisar wrote:
>> 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.
>
> I'm interested in how this should work when two different modules
> interact, and we need a language binding across both modules.
>
> Consider if we move the virtualization stack (QEMU & Libvirt) into a
> module with two streams, one libvirt 5.8.0 and one libvirt 6.1.0.
>
> Now we want to build Perl bindings for libvirt. We'll need the
> corresponding version of perl-Sys-Virt either 5.8.0 or 6.1.0,
> built for each virt module stream, but also built for each Perl
> module stream 5.26 / 5.30. eg the combinatorial expansion
>
> - perl-Sys-Virt 5.8.0 with libvirt 5.9.0 with perl 5.26
> - perl-Sys-Virt 5.8.0 with libvirt 5.9.0 with perl 5.30
> - perl-Sys-Virt 6.1.0 with libvirt 6.1.0 with perl 5.26
> - perl-Sys-Virt 6.1.0 with libvirt 6.1.0 with perl 5.30
>
True, you have 4 combinations.
> which module would the perl-Sys-Virt builds live in ?
>
> If perl-Sys-Virt is part of the virt module, IIUC we'd only be
> able to build it for one specific perl module stream.
>
> If perl-Sys-Virt is part of the perl module, IIUC we'd only be
> able to build it for one specific virt module stream
>
> It looks to me like we have to create a new module just to hold
> the perl-Sys-Virt package, and give this 4 streams, to cover the
> combinatorial expansion of the perl & virt module streams. Is
> this right ?
>
No. Modularity solves this combination problem with "stream expansion".
Sources for such module exists only once, you submit them for building
with fedpkg only once, but a build systems computes all combinations
(this the stream expansion) and schedules a build for each of the
combination. That will result in multiple module builds with the same
module name, stream, version, but differing with a special
discriminator called "context".
Example: Let's say you have libvirt module with 5.8.0 and 6.1.0 streams
and perl module with 5.26 and 5.30 streams. If you add perl-Sys-Virt
into a new module, you write a modulemd file for it like this:
- buildrequiers:
libvirt: [5.8.0, 6.1.0]
perl: [5.26, 5.30]
platform: [f32]
requires:
libvirt: [5.8.0, 6.1.0]
perl: [5.26, 5.30]
platform: [f32]
"fedpkg module-build" on it will spawn 4 builds. Even you don't have to
enumerate the streams and let the module build system to figure out it
automatically and expand for all existing:
- buildrequiers:
libvirt: []
perl: []
platform: []
requires:
libvirt: []
perl: []
platform: []
Or you can put perl-Sys-Virt into libvirt module and write into libvirt
modulemd of each of the libvirt streams:
- buildrequiers:
perl: []
platform: []
requires:
perl: []
platform: []
You can see these modules in RHEL or CentOS. E.g. perl-DBD-Pg module
<https://git.centos.org/modules/perl-DBD-Pg/blob/c8-stream-3.7/f/perl-DBD-Pg.yaml>.
When installing the module, DNF makes sure to select a proper context
for libvirt and perl you have already selected. If it happened that you
built it only for Perl 5.26, but you have already enabled Perl 5.24 on
your system, DNF will report an error that 5.26 module is needed but it
is disabled.
> And we'd have to do create more modules for every other language
> binding we ship (ocaml, python, ruby, etc) if the language runtime
> uses modules.
>
You can put all the bindings into one module. Or each binding into its
own module. Whatever fits your needs better.
-- 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
