Historically MinGW builds of software have been shipped in Fedora as completely separate source RPMs / components. This was known to be a high overhead approach when MinGW was first introduced to Fedora in circa 2010, but was none the less done because there was justifiable concern that MinGW support might be unstable and impose an unacceptable burden on existing maintainers of the native packages.

In the time since, the experience of MinGW maintainers is that it that the packages are not inherently less stable than their native equivalents. At the same time it has undeniably been a challenge for the MinGW maintainers to keep their packages matching the corresponding native packages. This has been particularly notable when people periodically produce reports of unfixed CVEs in Fedora, where MinGW packages have a disproportionally high presence.

IOW, by maintaining MinGW builds as separate source RPMs we have significantly added to the maintenance burden for Fedora maintainers as a collective whole, in order to avoid a burden on native package maintainers which in retrospect appears to be typically insignificant / not noteworthy.

With this in mind, there was a proposal on Fedora mailing lists to re-evaluate our original direction and merge MinGW packaging logic into the native specfiles.

https://lists.fedoraproject.org/archives/list/mingw@lists.fedoraproject.org/thread/DUEDGIOJNBBAMDIB4UYHDPP663HOVW6O/

then continued on

https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/FR5OEMAIROHKECQB2NGLMMXQGG7IQMHM/#XEABFLQVABR5VXCE2VTWVEIG6HQNOU7A

The resulting binary sub-RPMs are identical with the new approach, but the burden of dealing with a separate components is reduced. Half the number of bugzilla tickets for CVEs, half the number of koji builds to trigger (though the single build wallclock time is the same as the two separate builds combined), half the number of bohdi updates to issue, etc.

There was broad agreement in the above threads that this was a desirable thing to do, and the concept was put into practice by some MinGW package maintainers as detailed in

https://lists.fedoraproject.org/archives/list/mingw@lists.fedoraproject.org/thread/FEKJXDQC2SOHVINZAH3AGVDC7SE7SK7X/

The conversion was largely uneventful

• A few minor bugs in mingw RPM macros were fixed (%mingw_find_lang splattered the native lang file, since fixed)
• It became clear that mingw sub-RPMs should be conditional to only be done on Fedora, so that RHEL re-builds skip mingw as RHEL lacks the mingw toolchain

Since this approach has already been proven successful in about 35 packages, it is overdue to formally document this as a permissible (and indeed highly recommended) approach in MinGW packaging guidelines.

As alluded to earlier, the goal is to optimize such that the maintenance burden for Fedora maintainers as a collective whole is minimized. It is undeniable that this results in a slightly higher burden for the individual native package maintainers whose packages gain mingw support, but contrary to original fears, the burden is small enough that most maintainers won't be inconvenienced by it, and thus optimizing for the collective is a reasonable default approach.

Note, there is NOT any proposal to bulk convert existing mingw packages over to the integrated packaging approach. It would be at the discretion of existing mingw package maintainers to decide whether to try the conversion, subject to attaining agreement of the native package maintainer.