[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:       Igor Gnatenko <ignatenkobrain () fedoraproject ! org>
Date:       2019-11-19 11:14:30
Message-ID: CAFMg4WDXsPCqSPT8_T-8EGt90CujMMS8fj7SkScWS0ZLg9e3KQ () mail ! gmail ! com
[Download RAW message or body]

Yes, but what you have described is basically to create 2 streams of
perl-Sys-Virt module. Which is probably not what normal people want.
Creating module for one package is the worst idea ever.

Sure, bundling perl-Sys-Virt into the libvirt module would solve the
problem, but then what's the point of modules? You will be building
libvirt itself then multiple times due to the stream expansion.

On Tue, Nov 19, 2019 at 11:38 AM Petr Pisar <ppisar@redhat.com> wrote:
>
> 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
_______________________________________________
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]