[libvirt] [PATCH jenkins-ci 2/2] Enable mingw build for virt-viewer project

[Andrea Bolognani]

On Fri, 2018-04-13 at 13:44 +0100, Daniel P. Berrangé wrote:
> > Because of the missing dependencies mentioned below, you also need
> > 
> >   mingw32-hicolor-icon-theme:
> >     FedoraRawhide: mingw32-hicolor-icon-theme
> 
> There's no such package AFAIK

There sure is:

  $ dnf info mingw32-hicolor-icon-theme
  Available Packages
  Name         : mingw32-hicolor-icon-theme
  Version      : 0.16
  Release      : 1.fc28
  Arch         : noarch
  Size         : 45 k
  Source       : mingw-hicolor-icon-theme-0.16-1.fc28.src.rpm
  Repo         : rawhide
  Summary      : MinGW hicolor icon theme for MingGW
  URL          : http://icon-theme.freedesktop.org/releases/
  License      : GPLv2+
  Description  : Contains the basic directories and files needed for icon theme support.
               : This is the MinGW version of this package.

It's also listed as BuildRequires in mingw-virt-viewer.spec.in...

No, wait, actually its native variant is, but the same is true for
the Adwaita icon theme. Weird. I don't see how we would need one of
them to be native and the other to be MinGW, they should match.

> >   mingw32-spice-glib:
> >     FedoraRawhide: mingw32-spice-glib
> 
> That's not required - it is a dependency of spice-gtk3

But virt-viewer includes spice-glib headers directly, so it's good
practice not to rely on the transitive dependency and have a
direct one instead.

> > Same as the previous patch, you need to include also the packages
> > MinGW builds for libvirt and libvirt-glib already depend on.
> 
> Why would we want to duplicate that ?  This job depends on tje libvirt
> job, so that will have already pulled in all those RPMs.  Listing them
> again just creates the opportunity for the many duplicated listings to
> get out of date.

Please keep in mind the Ansible part is by design not tightly tied
to the Jenkins part, and must be usable entirely on its own for
development and debugging purposes.

That said, I've already agreed in the other mail that we don't
actually need to duplicate dependencies in this kind of scenario,
so disregard any comments to that effect.

-- 
Andrea Bolognani / Red Hat / Virtualization