Hi Fabian (and all the other participants in this thread), On Wed, 09 Nov 2011 13:33:14 +0100, Fabian Greffrath <fab...@greffrath.com> wrote: > Is there a principle behind all this or where can I help to clean this > up? ;)
The history has been explained by others. I've been working for a while on dropping at least gcc-mingw32; see #644769 which tracks the various packages build-depending on gcc-mingw32 and/or mingw32. There are only three packages left now; see #623400, #623402 and #623526. Patches are available for all the bugs so NMUs should be straightforward if they're deemed necessary - I could do the NMUs but I'd need a sponsor! On Thu, 10 Nov 2011 14:13:12 +0100, Fabian Greffrath <fab...@greffrath.com> wrote: > Furthermore, the gcc-mingw-w64 package, although misleadingly labeled > w64, is able to produce object code targeted at both the 32-bit and > 64-bit Windows platform. I'd thus suggest to split the package into > one component for each platform to avoid confusion and place > appropriate Replaces and Provides against the mingw32 package family. As far as the naming is concerned, see #622276 for details. I've thought about splitting the packages up, with separate 32- and 64-bit targets, but I'm not sure whether replacing and providing the mingw32 packages would be correct, since mingw-w64 isn't a drop-in replacement (the triplets are different). If that's not a problem then why not! The names for the 32-bit packages would probably be quite weird though since the upstream name is mingw-w64 (and I'd rather keep that in the package names...). Regards, Stephen
signature.asc
Description: PGP signature
