Ticket #812 (closed task: fixed)

Opened 2 years ago

Last modified 2 years ago

Mass rename request for all mingw32-* packages because of new packaging guidelines

Reported by: epienbro Owned by:
Priority: major Keywords: meeting
Cc: Blocked By:



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 and mingw64-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 against it.

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:

mingw32-SDL mingw32-SDL_image mingw32-SDL_mixer mingw32-atk mingw32-atkmm mingw32-binutils mingw32-boost mingw32-bzip2 mingw32-cairo mingw32-cairomm mingw32-celt051 mingw32-cppunit mingw32-crossreport mingw32-curl mingw32-cxxtest mingw32-dbus mingw32-dirac mingw32-dlfcn mingw32-enchant mingw32-expat mingw32-fontconfig mingw32-freeglut mingw32-freetype mingw32-gcc mingw32-gdbm mingw32-gdk-pixbuf mingw32-gettext mingw32-glib-networking mingw32-glib2 mingw32-glibmm24 mingw32-gnutls mingw32-gtk-vnc mingw32-gtk2 mingw32-gtkhtml3 mingw32-gtkmm24 mingw32-hunspell mingw32-jasper mingw32-libffi mingw32-libgcrypt mingw32-libgeotiff mingw32-libglade2 mingw32-libglademm24 mingw32-libgnurx mingw32-libgpg-error mingw32-libidn mingw32-libjpeg mingw32-libltdl mingw32-libogg mingw32-liboil mingw32-libp11 mingw32-libpng mingw32-libsigc++20 mingw32-libsigsegv mingw32-libsoup mingw32-libsqlite3x mingw32-libssh2 mingw32-libtiff mingw32-libvirt mingw32-libxml++ mingw32-libxml2 mingw32-libxslt mingw32-libzip mingw32-matahari mingw32-nsis mingw32-nsiswrapper mingw32-openjpeg mingw32-opensc mingw32-openssl mingw32-pango mingw32-pangomm mingw32-pcre mingw32-pdcurses mingw32-pixman mingw32-plotmm mingw32-portablexdr mingw32-proj mingw32-pthreads mingw32-qpid-cpp mingw32-qt mingw32-qt-qmake mingw32-qwt mingw32-readline mingw32-sigar mingw32-spice-protocol mingw32-sqlite mingw32-srvany mingw32-tcl mingw32-termcap mingw32-tk mingw32-webkitgtk mingw32-wpcap mingw32-xerces-c mingw32-zfstream mingw32-zlib

Thanks in advance,

Erik van Pienbroek Fedora MinGW SIG

Change History

comment:1 Changed 2 years ago by kevin

  • Keywords meeting added

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?

comment:2 Changed 2 years ago by epienbro

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

comment:3 Changed 2 years ago by notting

  • Resolution set to fixed
  • Status changed from new to closed

From the 2012-03-05 FESCo meeting:

  • AGREED: rename w/o re-review will be done in rawhide and merged for f17 if there are no problems

Go forth!

comment:4 Changed 2 years ago by epienbro

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

comment:5 Changed 2 years ago by notting

Sounds right.

comment:6 Changed 2 years ago by epienbro

Excellent, thanks!

Note: See TracTickets for help on using tickets.