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

[Daniel P. Berrangé]

On Fri, Apr 13, 2018 at 03:05:10PM +0200, Andrea Bolognani wrote:
> 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.

I think that highcolor line is obsolete cruft leftover when when
we added dep on mingw32 adwaita theme.

> > >   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.

If we really need that, then it would be better if we expressed
dependancies between the project vars files explicitly, rather
than duplicating information many times over

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|