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(a)gmail.com> wrote:
>
>
>
> On Tue, Mar 2, 2021 at 6:46 AM Richard W.M. Jones <rjones(a)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
--
|:
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 :|