[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fedora-devel-list
Subject:    Re: Modularity and the system-upgrade path
From:       Petr Pisar <ppisar () redhat ! com>
Date:       2019-11-19 10:31:20
Message-ID: slrnqt7h3o.6pv.ppisar () dhcp-0-146 ! brq ! redhat ! com
[Download RAW message or body]

On 2019-11-15, Igor Gnatenko <i.gnatenko.brain@gmail.com> wrote:
> On Fri, Nov 15, 2019, 17:38 Petr Pisar <ppisar@redhat.com> wrote:
>> On 2019-11-15, Daniel P  Berrang=C3=A9 <berrange@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
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-leave@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

[prev in list] [next in list] [prev in thread] [next in thread]