On Tue, Mar 02, 2021 at 11:21:16AM -0500, Neal Gompa wrote:

On Tue, Mar 2, 2021 at 11:13 AM Greg Hellings greg.hellings@gmail.com wrote:

...

On Tue, Mar 2, 2021 at 6:46 AM Richard W.M. Jones rjones@redhat.com wrote:

...

[Adding the devel list, since this change would obviously affect several "base" packages.]

On Mon, Mar 01, 2021 at 01:31:13PM +0000, 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