On Wed, 2018-05-16 at 10:49 +0200, Pavel Hrdina wrote:
> On Tue, May 15, 2018 at 04:40:08PM +0200, Andrea Bolognani wrote:
> > The MinGW variant of a build can assume native dependencies
> > are installed, so no need to spell them out again.
> > 
> > Signed-off-by: Andrea Bolognani <abolo...@redhat.com>
> > ---
> >  guests/vars/projects/libvirt+mingw.yml      | 2 --
> >  guests/vars/projects/libvirt-glib+mingw.yml | 4 ----
> >  guests/vars/projects/virt-viewer+mingw.yml  | 2 --
> >  3 files changed, 8 deletions(-)
> 
> I'm not sure about this one, yes our setup runs mingw builds only on
> systems where we run the native builds but we don't have it configured
> as strict dependency.

There was a discussion about a very similar issue a while ago,
sparked by

  https://www.redhat.com/archives/libvir-list/2018-April/msg01016.html

The bottom line for me is that non-native builds are something
you might decide to perform in addition to native builds (see
that + sign there? ;), so it's perfectly reasonable not to list
native dependencies for the MinGW variant.

It's true that we don't have a mechanism to ensure this
relationship is enforced, but as long as we don't start getting
a lot of external contributions I think reviews are a good
enough bar to clear.

I also plan to actually document this formally, along with the
other kind of relationship we need to concern ourselves with:
that between eg. libvirt-glib and libvirt, where the former can
only be built after building the latter, and as such doesn't
need to explicitly depend on any package the latter already
depends on. There's also some more cleaning up to do there, I
just haven't gotten around to it yet :)

-- 
Andrea Bolognani / Red Hat / Virtualization

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Reply via email to