Re: Merging mingw specs into native spec
On Wed, Mar 03, 2021 at 09:29:43AM +0100, Petr Pisar wrote:
> V Tue, Mar 02, 2021 at 12:45:42PM +, Richard W.M. Jones napsal(a):
> > On Mon, Mar 01, 2021 at 01:31:13PM +, Daniel P. Berrangé wrote:
> > > +%if %{_with_mingw}
> > > +
> > > +%package -n mingw32-libvirt-glib
> > > +Summary: MingwGW Windows libvirt-gconfig virtualization library
> > > +BuildArch: noarch
> > > +Requires: pkgconfig
> > > +
>
> Why are the packages noarch if they contain a machine code?
Dan already noted that you can run the cross-compiler on any
architecture.
However it is a good question about why the final packages are
"noarch". Windows these days only exists on i686, x86-64 and aarch64.
I don't know what mingw-w64's support for aarch64 is like, but we only
bother building i686 ("mingw32-*") and x86-64 ("mingw64-*") packages.
Normally the end result is intended to be run on Windows, so it's
"noarch" as far as Fedora is concerned. The normal deployment method
is to use NSIS to generate an installer (from files in the RPMs you've
installed locally) which is copied over to Windows. You can do this
on any arch. But you can also run the code under Wine on an x86-64
host. Probably on i686 host but I doubt anyone has done that in a
long while. Wine doesn't work on non-x86 arches.
I don't think that Koji / RPM is really designed to cope with all this
subtlety though. And implementing it just for mingw is way too much work.
> Fullarch Linux packages are built on various architectures. Is MinGW
> toolchain available on all of them? E.g if my Linux package builds
> on s390x, is there a crosscompiler available and is thus possible to
> build Windows binaries there? What about runnning tests in %check
> phase?
Yes, any build arch can be used. We don't usually run tests in %check
because running Wine under Koji is a pain. It requires a specifically
configured $HOME, and X server (even for console programs).
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Merging mingw specs into native spec
On Wed, Mar 03, 2021 at 09:29:43AM +0100, Petr Pisar wrote:
> V Tue, Mar 02, 2021 at 12:45:42PM +, Richard W.M. Jones napsal(a):
> > On Mon, Mar 01, 2021 at 01:31:13PM +, Daniel P. Berrangé wrote:
> > > +%if %{_with_mingw}
> > > +
> > > +%package -n mingw32-libvirt-glib
> > > +Summary: MingwGW Windows libvirt-gconfig virtualization library
> > > +BuildArch: noarch
> > > +Requires: pkgconfig
> > > +
>
> Why are the packages noarch if they contain a machine code?
>
> Fullarch Linux packages are built on various architectures. Is MinGW toolchain
> available on all of them? E.g if my Linux package builds on s390x, is
> there a crosscompiler available and is thus possible to build Windows
> binaries there? What about runnning tests in %check phase?
The mingw toolchain is a cross compiler, and available on all Fedora
arches, so it doesn't matter what arch we build the DLLs on. Generally
we dont run tests in %check for mingw, but in theory you could use
wine to do this.
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 :|
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Merging mingw specs into native spec
V Tue, Mar 02, 2021 at 12:45:42PM +, Richard W.M. Jones napsal(a):
> On Mon, Mar 01, 2021 at 01:31:13PM +, Daniel P. Berrangé wrote:
> > +%if %{_with_mingw}
> > +
> > +%package -n mingw32-libvirt-glib
> > +Summary: MingwGW Windows libvirt-gconfig virtualization library
> > +BuildArch: noarch
> > +Requires: pkgconfig
> > +
Why are the packages noarch if they contain a machine code?
Fullarch Linux packages are built on various architectures. Is MinGW toolchain
available on all of them? E.g if my Linux package builds on s390x, is
there a crosscompiler available and is thus possible to build Windows
binaries there? What about runnning tests in %check phase?
-- Petr
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
Re: Merging mingw specs into native spec
On Tue, Mar 02, 2021 at 11:21:16AM -0500, Neal Gompa wrote: > On Tue, Mar 2, 2021 at 11:13 AM Greg Hellings wrote: > > > > > > > > On Tue, Mar 2, 2021 at 6:46 AM Richard W.M. Jones wrote: > >> > >> [Adding the devel list, since this change would obviously affect > >> several "base" packages.] > >> > >> On Mon, Mar 01, 2021 at 01:31:13PM +, Daniel P. Berrangé wrote: snip > >> > In summary based on my tests I think killing off the separate dist-git > >> > / RPM spec for mingw looks feasible unless someone knows of hidden > >> > show stoppers I haven't hit yet. > >> > > >> > I think we should go ahead and do this for some packages to demonstrate > >> > the concept in the real world, and I'm volunteering to coordinate it for > >> > all the virtualization packages I'm involved in maint of because I can't > >> > even reliably keep them in sync myself. libvirt, libvirt-glib, libosinfo, > >> > osinfo-db-tools, gtk-vnc, spice-gtk all use meson, so should mirror the > >> > approach above and be quite easy. > >> > > >> > Once we can demonstrate the real world impact, we can socialize the idea > >> > on Fedora devel list more widely and then also approach maintainers > >> > of other native packages to attempt to convince them to accept mingw > >> > sub-RPMs into their specs. Every mingw package we can get merged into > >> > native package frees up a little more time for to spend on the remaining > >> > mingw packages that are still separate. Ideally we'd get 100% merged > >> > long term, but even if we get refusals from native maintainers, we'll > >> > still be better off with those we do succeed in merging. > >> > > >> > Regards, > >> > Daniel > >> > >> Sounds in general like a good idea, but I think we should make it > >> opt-in only for the foreseeable future. Some packagers won't > >> appreciate the extra overhead of all the mingw stuff. > > > > > > I, for one, welcome this. For several of the packages I maintain, I'm the > > only person to support them in both native and mingw biulds. > > > > Do you have a suggested path I would take to deprecate the mingw-foo > > packages once I roll over building them into the native package? > > > > I'm also happy about this. I think we should get some packages > converted in a COPR so we can see this more concretely. I think we can > also make some improvements here for this so that we don't have to do > weird overrides of RPM macros too by making adjustments to > redhat-rpm-config. If people have ideas on how to improve the standard macros to simplify mingw additions I'm all for it. > Can we have a COPR going soon to have some examples showing how this > works? Then I can take a look more concretely on how this works and > see if I can help make this smoother. Sure, I can do builds of a few of the virt packages in my copr to illustrate it 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 :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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 Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: Merging mingw specs into native spec
On Tue, Mar 02, 2021 at 10:13:38AM -0600, Greg Hellings wrote:
> On Tue, Mar 2, 2021 at 6:46 AM Richard W.M. Jones wrote:
>
> > [Adding the devel list, since this change would obviously affect
> > several "base" packages.]
> >
> > On Mon, Mar 01, 2021 at 01:31:13PM +, Daniel P. Berrangé wrote:
> > > Way back when we first started the mingw project in Fedora we took the
> > > decision to maintain the mingw builds as separate source RPMs in Fedora.
> > > The rationale was that mingw support was a new concept to Fedora with
> > > many unknowns. We often had custom mingw only patches, and there was a
> > > decent chance there would be breakage upon rebases. We didn't want to
> > > burden the native package maintainers with mingw support as that would
> > > have increased pushback against the effort.
> > >
> > > This decision was always going to cause us problems with keeping the
> > > mingw dist-git packages in sync with native dist-git packages. This
> > > is especially important when it comes to security fixes, and there
> > > have been reasonably well justified complaints about mingw lagging
> > > native wrt to CVE fixing in recent times.
> > >
> > >
> > > Since the early days we merged the separate mingw32-$PKG / mingw64-$PKG
> > > source RPMS into a single mingw-$PKG in dist-git. The need for patching
> > > mingw RPMs to fix problems in Fedora doesn't seem any higher than the
> > > need for patching to fix native build problem. Generally things just
> > > work when rebasing, because most upstreams recognize the importance
> > > of keeping their projects working on mingw.
> > >
> > > IOW, we were afraid of a maintainer burden that has turned out to
> > > largely not exist. To address this non-existant burden, we intentionally
> > > made the maint of mingw packages harder than it needs to be in Fedora.
> > >
> > >
> > > This is a long winded way of saying I think it is time to update
> > > the mingw packaging guidelines to allow for, even recommend, mingw
> > > packaging to be a standard part of the native RPM spec. In doing
> > > so we eliminate the main burden of mingw packaging in Feora and
> > > guarantee that we'll always be up to date wrt bug/security fixes
> > > and rebases.
> > >
> > > I've done some basic tests with libvirt-glib upstream which recently
> > > changed to using Meson. Supporting mingw in the main libvirt-glib.spec
> > > was largely trivial. I simply needed to copy the various blocks of
> > > the mingw-libvirt-glib.spec file into the libvirt-glib.spec, ending
> > > up with a diff:
snip
> > > In summary based on my tests I think killing off the separate dist-git
> > > / RPM spec for mingw looks feasible unless someone knows of hidden
> > > show stoppers I haven't hit yet.
> > >
> > > I think we should go ahead and do this for some packages to demonstrate
> > > the concept in the real world, and I'm volunteering to coordinate it for
> > > all the virtualization packages I'm involved in maint of because I can't
> > > even reliably keep them in sync myself. libvirt, libvirt-glib, libosinfo,
> > > osinfo-db-tools, gtk-vnc, spice-gtk all use meson, so should mirror the
> > > approach above and be quite easy.
> > >
> > > Once we can demonstrate the real world impact, we can socialize the idea
> > > on Fedora devel list more widely and then also approach maintainers
> > > of other native packages to attempt to convince them to accept mingw
> > > sub-RPMs into their specs. Every mingw package we can get merged into
> > > native package frees up a little more time for to spend on the remaining
> > > mingw packages that are still separate. Ideally we'd get 100% merged
> > > long term, but even if we get refusals from native maintainers, we'll
> > > still be better off with those we do succeed in merging.
> > >
> > Sounds in general like a good idea, but I think we should make it
> > opt-in only for the foreseeable future. Some packagers won't
> > appreciate the extra overhead of all the mingw stuff.
> >
>
> I, for one, welcome this. For several of the packages I maintain, I'm the
> only person to support them in both native and mingw biulds.
>
> Do you have a suggested path I would take to deprecate the mingw-foo
> packages once I roll over building them into the native package?
The mingw{32,64}-foo sub-RPMs generated from the native foo.spec file
would have identical contents + names to the current mingw RPMs generated
from the mingw-foo.spec
IOW, there is no deprecation/upgrade path involved. Once we have a build
of mingw RPMs from the native spec, then we just immediately retire the
corresponding mingw dist-git repo. The user of Fedora sees no change at
all. The only thing is to ensure the native NEVR is newer than the
original mingw RPM NEVR, which it almost always is already.
Regards,
Daniel
--
|: https://berrange.com -o-https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o-https://fstop138.berrange.com :|
|: https://entangle-phot
Re: Merging mingw specs into native spec
On Tue, Mar 2, 2021 at 11:13 AM Greg Hellings wrote:
>
>
>
> On Tue, Mar 2, 2021 at 6:46 AM Richard W.M. Jones wrote:
>>
>> [Adding the devel list, since this change would obviously affect
>> several "base" packages.]
>>
>> On Mon, Mar 01, 2021 at 01:31:13PM +, Daniel P. Berrangé wrote:
>> > Way back when we first started the mingw project in Fedora we took the
>> > decision to maintain the mingw builds as separate source RPMs in Fedora.
>> > The rationale was that mingw support was a new concept to Fedora with
>> > many unknowns. We often had custom mingw only patches, and there was a
>> > decent chance there would be breakage upon rebases. We didn't want to
>> > burden the native package maintainers with mingw support as that would
>> > have increased pushback against the effort.
>> >
>> > This decision was always going to cause us problems with keeping the
>> > mingw dist-git packages in sync with native dist-git packages. This
>> > is especially important when it comes to security fixes, and there
>> > have been reasonably well justified complaints about mingw lagging
>> > native wrt to CVE fixing in recent times.
>> >
>> >
>> > Since the early days we merged the separate mingw32-$PKG / mingw64-$PKG
>> > source RPMS into a single mingw-$PKG in dist-git. The need for patching
>> > mingw RPMs to fix problems in Fedora doesn't seem any higher than the
>> > need for patching to fix native build problem. Generally things just
>> > work when rebasing, because most upstreams recognize the importance
>> > of keeping their projects working on mingw.
>> >
>> > IOW, we were afraid of a maintainer burden that has turned out to
>> > largely not exist. To address this non-existant burden, we intentionally
>> > made the maint of mingw packages harder than it needs to be in Fedora.
>> >
>> >
>> > This is a long winded way of saying I think it is time to update
>> > the mingw packaging guidelines to allow for, even recommend, mingw
>> > packaging to be a standard part of the native RPM spec. In doing
>> > so we eliminate the main burden of mingw packaging in Feora and
>> > guarantee that we'll always be up to date wrt bug/security fixes
>> > and rebases.
>> >
>> > I've done some basic tests with libvirt-glib upstream which recently
>> > changed to using Meson. Supporting mingw in the main libvirt-glib.spec
>> > was largely trivial. I simply needed to copy the various blocks of
>> > the mingw-libvirt-glib.spec file into the libvirt-glib.spec, ending
>> > up with a diff:
>> >
>> > diff --git a/libvirt-glib.spec.in b/libvirt-glib.spec.in
>> > index 58e6242..81f972b 100644
>> > --- a/libvirt-glib.spec.in
>> > +++ b/libvirt-glib.spec.in
>> > @@ -1,5 +1,15 @@
>> > # -*- rpm-spec -*-
>> >
>> > +%bcond_without mingw
>> > +
>> > +%define _with_mingw 0
>> > +%if 0%{?fedora}
>> > +%define _with_mingw 0%{with mingw}
>> > +%endif
>> > +
>> > +%define mingw32_pkg_name mingw32-%{name}
>> > +%define mingw64_pkg_name mingw64-%{name}
>> > +
>> > Name: libvirt-glib
>> > Version: @VERSION@
>> > Release: 1%{?dist}
>> > @@ -16,6 +26,16 @@ BuildRequires: libxml2-devel
>> > BuildRequires: vala-tools
>> > BuildRequires: gettext
>> >
>> > +%if %{_with_mingw}
>> > +BuildRequires: mingw32-filesystem
>> > +BuildRequires: mingw64-filesystem
>> > +BuildRequires: mingw32-glib2
>> > +BuildRequires: mingw64-glib2
>> > +BuildRequires: mingw32-libvirt
>> > +BuildRequires: mingw64-libvirt
>> > +%endif
>> > +
>> > +
>> > %package devel
>> > Summary: libvirt glib integration for events development files
>> > Requires: %{name} = %{version}-%{release}
>> > @@ -37,6 +57,42 @@ Requires: libvirt-gconfig-devel = %{version}-%{release}
>> > Requires: libvirt-gobject = %{version}-%{release}
>> > Requires: libvirt-devel
>> >
>> > +
>> > +%if %{_with_mingw}
>> > +
>> > +%package -n mingw32-libvirt-glib
>> > +Summary: MingwGW Windows libvirt-gconfig virtualization library
>> > +BuildArch: noarch
>> > +Requires: pkgconfig
>> > +
>> > +%package -n mingw32-libvirt-gconfig
>> > +Summary: MingwGW Windows libvirt-gconfig virtualization library
>> > +BuildArch: noarch
>> > +Requires: pkgconfig
>> > +
>> > +%package -n mingw32-libvirt-gobject
>> > +Summary: MingwGW Windows libvirt-gobject virtualization library
>> > +BuildArch: noarch
>> > +Requires: pkgconfig
>> > +
>> > +%package -n mingw64-libvirt-glib
>> > +Summary: MingwGW Windows libvirt-gconfig virtualization library
>> > +BuildArch: noarch
>> > +Requires: pkgconfig
>> > +
>> > +%package -n mingw64-libvirt-gconfig
>> > +Summary: MingwGW Windows libvirt-gconfig virtualization library
>> > +BuildArch: noarch
>> > +Requires: pkgconfig
>> > +
>> > +%package -n mingw64-libvirt-gobject
>> > +Summary: MingwGW Windows libvirt-gobject virtualization library
>> > +BuildArch: noarch
>> > +Requires: pkgconfig
>> > +
>> > +%endif
>> > +
>> > +
>> > %description
>> > This package provides integration between libvirt and the glib
>> > event loop.
>> > @@ -61,6 +117,31 @@ objects
>> > This package provides de
Re: Merging mingw specs into native spec
On Tue, Mar 2, 2021 at 6:46 AM Richard W.M. Jones wrote:
> [Adding the devel list, since this change would obviously affect
> several "base" packages.]
>
> On Mon, Mar 01, 2021 at 01:31:13PM +, Daniel P. Berrangé wrote:
> > Way back when we first started the mingw project in Fedora we took the
> > decision to maintain the mingw builds as separate source RPMs in Fedora.
> > The rationale was that mingw support was a new concept to Fedora with
> > many unknowns. We often had custom mingw only patches, and there was a
> > decent chance there would be breakage upon rebases. We didn't want to
> > burden the native package maintainers with mingw support as that would
> > have increased pushback against the effort.
> >
> > This decision was always going to cause us problems with keeping the
> > mingw dist-git packages in sync with native dist-git packages. This
> > is especially important when it comes to security fixes, and there
> > have been reasonably well justified complaints about mingw lagging
> > native wrt to CVE fixing in recent times.
> >
> >
> > Since the early days we merged the separate mingw32-$PKG / mingw64-$PKG
> > source RPMS into a single mingw-$PKG in dist-git. The need for patching
> > mingw RPMs to fix problems in Fedora doesn't seem any higher than the
> > need for patching to fix native build problem. Generally things just
> > work when rebasing, because most upstreams recognize the importance
> > of keeping their projects working on mingw.
> >
> > IOW, we were afraid of a maintainer burden that has turned out to
> > largely not exist. To address this non-existant burden, we intentionally
> > made the maint of mingw packages harder than it needs to be in Fedora.
> >
> >
> > This is a long winded way of saying I think it is time to update
> > the mingw packaging guidelines to allow for, even recommend, mingw
> > packaging to be a standard part of the native RPM spec. In doing
> > so we eliminate the main burden of mingw packaging in Feora and
> > guarantee that we'll always be up to date wrt bug/security fixes
> > and rebases.
> >
> > I've done some basic tests with libvirt-glib upstream which recently
> > changed to using Meson. Supporting mingw in the main libvirt-glib.spec
> > was largely trivial. I simply needed to copy the various blocks of
> > the mingw-libvirt-glib.spec file into the libvirt-glib.spec, ending
> > up with a diff:
> >
> > diff --git a/libvirt-glib.spec.in b/libvirt-glib.spec.in
> > index 58e6242..81f972b 100644
> > --- a/libvirt-glib.spec.in
> > +++ b/libvirt-glib.spec.in
> > @@ -1,5 +1,15 @@
> > # -*- rpm-spec -*-
> >
> > +%bcond_without mingw
> > +
> > +%define _with_mingw 0
> > +%if 0%{?fedora}
> > +%define _with_mingw 0%{with mingw}
> > +%endif
> > +
> > +%define mingw32_pkg_name mingw32-%{name}
> > +%define mingw64_pkg_name mingw64-%{name}
> > +
> > Name: libvirt-glib
> > Version: @VERSION@
> > Release: 1%{?dist}
> > @@ -16,6 +26,16 @@ BuildRequires: libxml2-devel
> > BuildRequires: vala-tools
> > BuildRequires: gettext
> >
> > +%if %{_with_mingw}
> > +BuildRequires: mingw32-filesystem
> > +BuildRequires: mingw64-filesystem
> > +BuildRequires: mingw32-glib2
> > +BuildRequires: mingw64-glib2
> > +BuildRequires: mingw32-libvirt
> > +BuildRequires: mingw64-libvirt
> > +%endif
> > +
> > +
> > %package devel
> > Summary: libvirt glib integration for events development files
> > Requires: %{name} = %{version}-%{release}
> > @@ -37,6 +57,42 @@ Requires: libvirt-gconfig-devel =
> %{version}-%{release}
> > Requires: libvirt-gobject = %{version}-%{release}
> > Requires: libvirt-devel
> >
> > +
> > +%if %{_with_mingw}
> > +
> > +%package -n mingw32-libvirt-glib
> > +Summary: MingwGW Windows libvirt-gconfig virtualization library
> > +BuildArch: noarch
> > +Requires: pkgconfig
> > +
> > +%package -n mingw32-libvirt-gconfig
> > +Summary: MingwGW Windows libvirt-gconfig virtualization library
> > +BuildArch: noarch
> > +Requires: pkgconfig
> > +
> > +%package -n mingw32-libvirt-gobject
> > +Summary: MingwGW Windows libvirt-gobject virtualization library
> > +BuildArch: noarch
> > +Requires: pkgconfig
> > +
> > +%package -n mingw64-libvirt-glib
> > +Summary: MingwGW Windows libvirt-gconfig virtualization library
> > +BuildArch: noarch
> > +Requires: pkgconfig
> > +
> > +%package -n mingw64-libvirt-gconfig
> > +Summary: MingwGW Windows libvirt-gconfig virtualization library
> > +BuildArch: noarch
> > +Requires: pkgconfig
> > +
> > +%package -n mingw64-libvirt-gobject
> > +Summary: MingwGW Windows libvirt-gobject virtualization library
> > +BuildArch: noarch
> > +Requires: pkgconfig
> > +
> > +%endif
> > +
> > +
> > %description
> > This package provides integration between libvirt and the glib
> > event loop.
> > @@ -61,6 +117,31 @@ objects
> > This package provides development header files and libraries for
> > managing virtualization host objects
> >
> > +%if %{_with_mingw}
> > +
> > +%description -n mingw32-libvirt-glib
> > +MinGW Windows libvirt-gl
Merging mingw specs into native spec
[Adding the devel list, since this change would obviously affect
several "base" packages.]
On Mon, Mar 01, 2021 at 01:31:13PM +, Daniel P. Berrangé wrote:
> Way back when we first started the mingw project in Fedora we took the
> decision to maintain the mingw builds as separate source RPMs in Fedora.
> The rationale was that mingw support was a new concept to Fedora with
> many unknowns. We often had custom mingw only patches, and there was a
> decent chance there would be breakage upon rebases. We didn't want to
> burden the native package maintainers with mingw support as that would
> have increased pushback against the effort.
>
> This decision was always going to cause us problems with keeping the
> mingw dist-git packages in sync with native dist-git packages. This
> is especially important when it comes to security fixes, and there
> have been reasonably well justified complaints about mingw lagging
> native wrt to CVE fixing in recent times.
>
>
> Since the early days we merged the separate mingw32-$PKG / mingw64-$PKG
> source RPMS into a single mingw-$PKG in dist-git. The need for patching
> mingw RPMs to fix problems in Fedora doesn't seem any higher than the
> need for patching to fix native build problem. Generally things just
> work when rebasing, because most upstreams recognize the importance
> of keeping their projects working on mingw.
>
> IOW, we were afraid of a maintainer burden that has turned out to
> largely not exist. To address this non-existant burden, we intentionally
> made the maint of mingw packages harder than it needs to be in Fedora.
>
>
> This is a long winded way of saying I think it is time to update
> the mingw packaging guidelines to allow for, even recommend, mingw
> packaging to be a standard part of the native RPM spec. In doing
> so we eliminate the main burden of mingw packaging in Feora and
> guarantee that we'll always be up to date wrt bug/security fixes
> and rebases.
>
> I've done some basic tests with libvirt-glib upstream which recently
> changed to using Meson. Supporting mingw in the main libvirt-glib.spec
> was largely trivial. I simply needed to copy the various blocks of
> the mingw-libvirt-glib.spec file into the libvirt-glib.spec, ending
> up with a diff:
>
> diff --git a/libvirt-glib.spec.in b/libvirt-glib.spec.in
> index 58e6242..81f972b 100644
> --- a/libvirt-glib.spec.in
> +++ b/libvirt-glib.spec.in
> @@ -1,5 +1,15 @@
> # -*- rpm-spec -*-
>
> +%bcond_without mingw
> +
> +%define _with_mingw 0
> +%if 0%{?fedora}
> +%define _with_mingw 0%{with mingw}
> +%endif
> +
> +%define mingw32_pkg_name mingw32-%{name}
> +%define mingw64_pkg_name mingw64-%{name}
> +
> Name: libvirt-glib
> Version: @VERSION@
> Release: 1%{?dist}
> @@ -16,6 +26,16 @@ BuildRequires: libxml2-devel
> BuildRequires: vala-tools
> BuildRequires: gettext
>
> +%if %{_with_mingw}
> +BuildRequires: mingw32-filesystem
> +BuildRequires: mingw64-filesystem
> +BuildRequires: mingw32-glib2
> +BuildRequires: mingw64-glib2
> +BuildRequires: mingw32-libvirt
> +BuildRequires: mingw64-libvirt
> +%endif
> +
> +
> %package devel
> Summary: libvirt glib integration for events development files
> Requires: %{name} = %{version}-%{release}
> @@ -37,6 +57,42 @@ Requires: libvirt-gconfig-devel = %{version}-%{release}
> Requires: libvirt-gobject = %{version}-%{release}
> Requires: libvirt-devel
>
> +
> +%if %{_with_mingw}
> +
> +%package -n mingw32-libvirt-glib
> +Summary: MingwGW Windows libvirt-gconfig virtualization library
> +BuildArch: noarch
> +Requires: pkgconfig
> +
> +%package -n mingw32-libvirt-gconfig
> +Summary: MingwGW Windows libvirt-gconfig virtualization library
> +BuildArch: noarch
> +Requires: pkgconfig
> +
> +%package -n mingw32-libvirt-gobject
> +Summary: MingwGW Windows libvirt-gobject virtualization library
> +BuildArch: noarch
> +Requires: pkgconfig
> +
> +%package -n mingw64-libvirt-glib
> +Summary: MingwGW Windows libvirt-gconfig virtualization library
> +BuildArch: noarch
> +Requires: pkgconfig
> +
> +%package -n mingw64-libvirt-gconfig
> +Summary: MingwGW Windows libvirt-gconfig virtualization library
> +BuildArch: noarch
> +Requires: pkgconfig
> +
> +%package -n mingw64-libvirt-gobject
> +Summary: MingwGW Windows libvirt-gobject virtualization library
> +BuildArch: noarch
> +Requires: pkgconfig
> +
> +%endif
> +
> +
> %description
> This package provides integration between libvirt and the glib
> event loop.
> @@ -61,6 +117,31 @@ objects
> This package provides development header files and libraries for
> managing virtualization host objects
>
> +%if %{_with_mingw}
> +
> +%description -n mingw32-libvirt-glib
> +MinGW Windows libvirt-glib virtualization library.
> +
> +%description -n mingw32-libvirt-gconfig
> +MinGW Windows libvirt-gconfig virtualization library.
> +
> +%description -n mingw32-libvirt-gobject
> +MinGW Windows libvirt-gobject virtualization library.
> +
> +
> +%description -n mingw64-libvirt-glib
> +MinGW Windows libvirt-
