On Fri, Nov 15, 2019, 17:38 Petr Pisar <ppi...@redhat.com> wrote: > On 2019-11-15, Daniel P Berrangé <berra...@redhat.com> wrote: > > On Fri, Nov 15, 2019 at 02:53:08PM -0000, Petr Pisar wrote: > >> On 2019-11-15, John M. Harris Jr <joh...@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. > > > > 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". >
The problem described by Daniel was that Perl module should be different version when building against 5.x libvirt. 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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
