Re: Modularity and the system-upgrade path

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2019-11-15, Igor Gnatenko <i.gnatenko.brain@xxxxxxxxx> wrote:
> On Fri, Nov 15, 2019, 17:38 Petr Pisar <ppisar@xxxxxxxxxx> wrote:
>> On 2019-11-15, Daniel P  Berrang=C3=A9 <berrange@xxxxxxxxxx> 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@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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux