Over the last year we (the Fedora MinGW SIG) have been working on
adding support for the mingw-w64 toolchain which can be used to
generate binaries for both win32 and win64 targets. Part of this
is a set of new packaging guidelines which has already been approved
by the FPC some time ago: https://fedoraproject.org/wiki/Packaging:MinGW_Future
The main difference between the original MinGW packaging guidelines
and these new guidelines is the naming of source packages. With the
original MinGW packaging guidelines packages had to start with the
prefix 'mingw32-'. With the new guidelines this has changed to 'mingw-'.
This change was introduced to make it possible to generate binary packages
for both win32 and win64 targets from a single .spec file. For example the
source package mingw-gtk3 can now provide binary packages named mingw32-gtk3
The introduction of mingw-w64 in Fedora has been pending on the approval
of Red Hat Legal for an entire year, but a few days ago we received word that
there were no more pending legal issues so we could continue with the
introduction of the mingw-w64 toolchain in Fedora.
The base toolchain packages belonging to the mingw-w64 toolchain (mingw-crt
and mingw-headers) have already been approved in the review process and all
current mingw* packages in Fedora 17/rawhide have been successfully rebuilt
The next step is to make the current mingw* packages compliant to these
new packaging guidelines.
After approval of the new packaging guidelines the FPC also made a change
to the old packaging guidelines which states the new mingw packages can
be named 'mingw-*' to make the transition to the new packaging guidelines
more easy: https://fedoraproject.org/wiki/Packaging:MinGW#Package_naming
Before we can make the current mingw32-* packages compliant with these
new packaging guidelines a rename has to take place first. The regular
guidelines state that for every rename a complete review request has to
be performed first. As there currently are almost 100 different packages
which use the 'mingw32-' prefix this isn't really a practical method for us.
Therefore we would like to ask FESCO for an exception to the regular
package rename guidelines. We would like to ask you for a mass rename
of all mingw32- packages to be renamed to mingw-. We would like to
have branches created for both rawhide and F17. The original package
maintainers/co-maintainers of the packages can remain the same.
Here is a list of packages which we would like to have renamed:
Thanks in advance,
Erik van Pienbroek
Fedora MinGW SIG
Well, the reasoning for requiring a re-review in the past has been primarily that people tend to screw up the Provides and Obsoletes for the new packages.
I assume you intend to retire all the old ones and Provide/Obsolete them in the new subpackages?
Are you going to automate this import somehow? Or just go one by one?
The use of obsoletes/provides tag won't be necessary here as the
naming of the binary packages won't change.
Take for example the mingw32-glib2 package. The spec file is currently
named mingw32-glib2.spec and it produces a binary RPM called mingw32-glib2.
For a renamed package the spec file is renamed to mingw-glib2.spec.
However, this package doesn't create a binary RPM called mingw-glib2, but
it creates two binary RPMs called mingw32-glib2 and mingw64-glib2 (one
for win32 support, one for win64 support). The version numbering will
remain the same. Therefore yum won't see any difference between the
old and the new packages
Because of the pending legal issues I mentioned earlier we had to do our
testing in a separate yum repository. About 2/3rd of all mingw32-* packages
are already ported to the new packaging guidelines (and thus the new naming)
so for those it's just a plain move from the testing repo to Fedora git.
We plan to port the remaining packages in the next days/weeks
Once a ported (mingw-) package is imported in Fedora the plan is to retire
the original (mingw32-) package
From the 2012-03-05 FESCo meeting:
Thanks for the approval!
Could you please confirm if my interpretation of the meeting logs is correct regarding the actions below?
File individual bugzilla tickets containing just the new package SCM requests for each mingw32- package and where a F-17 branch is also requested
Set the fedora-review flag in these bugzilla tickets to '+' with a comment referring to this approval so that a re-review is not needed
Set the fedora-cvs flag to '?' and wait for the git repos to be created
Import and build the renamed packages in rawhide
(After 2 days) merge the renamed packages to F-17
File a rel-eng ticket to block the old mingw32- packages from F-17 and rawhide
to comment on this ticket.
Copyright © 2014-2016 Red Hat