On 2019-11-15, Igor Gnatenko <i.gnatenko.brain(a)gmail.com> wrote:
On Fri, Nov 15, 2019, 17:38 Petr Pisar <ppisar(a)redhat.com>
wrote:
> On 2019-11-15, Daniel P Berrang=C3=A9 <berrange(a)redhat.com> wrote:
> >
> > 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
[...]
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]
>
You are right. Then either you put perl-Sys-Virt 5.8.0 into
a perl-Sys-Virt:5.8.0 stream with this dependency specification:
- buildrequiers:
libvirt: [5.9.0]
perl: [5.26, 5.30]
platform: [f32]
requires:
libvirt: [5.9.0]
perl: [5.26, 5.30]
platform: [f32]
and perl-Sys-Virt 6.1.0 package into perl-Sys-Virt:6.1.0 stream with:
- buildrequiers:
libvirt: [6.1.0]
perl: [5.26, 5.30]
platform: [f32]
requires:
libvirt: [6.1.0]
perl: [5.26, 5.30]
platform: [f32]
Or you put perl-Sys-Virt package into libvirt module and for
libvirt:5.9.0 stream you write:
- buildrequiers:
perl: [5.26, 5.30]
platform: [f32]
requires:
perl: [5.26, 5.30]
platform: [f32]
and for libvirt:6.1.0 stream you do the same.
What approach you want to choose probably depends on compatibility
among perl-Sys-Virt package versions and among libvirt versions. And how
often they are released.
I.e. if you can rebase perl-Sys-Virt inside libvirt stream because
perl-Sys-Virt does not break ABI, then it makes sense to keep it inside
libvirt module. That's because public ABI of a module should not change
inside a stream.
You can also consider how expensive is to build, test and deliver the
libvirt module. If e.g. building perl-Sys-Virt were much quicker than
building libvirt, and there were plenty of perl streams, then it would
make sense to move perl-Sys-Virt package into its own module.
I think it's a similar problem as to when bundle all dependencies into
one package and when to aim for splitting it into muliple independent
packages.
-- Petr