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@xxxxxxxxx> wrote: > > > > > > > > On Tue, Mar 2, 2021 at 6:46 AM Richard W.M. Jones <rjones@xxxxxxxxxx> 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 -- |: 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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
