Hi Stephen, I was hoping you'd actually been cc'd on this :)
On Thu, Nov 10, 2011 at 08:16:01PM +0100, Stephen Kitt wrote: > 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! Ewww, why on earth did they change the triplet for the 32bit builds? It's not actually a different architecture, or even a substantially different toolchain. If you've actually got this all building from the mainline sources now, I'd have been all for folding this into the original mingw packages and having some sort of sensible (if somewhat interrupted :) continuity for people down that track ... but if it's gratuitously incompatible, then I don't really know what to do or think about that ... modulo pity for the people getting burned. > 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...). I'm not sure I really follow this, what am I missing here? What exactly are you taking from 'upstream' in this case? My understanding was that the toolchain was mainline gcc/binutils now, and all that the w64 folk were providing was the runtime library? Is that wrong? mingw.org has been basically dead for quite some time now, the 'developer' list has been closed to the public and the only apparent work going on was for native windows installers. They were even claiming that building it for platforms other than windows was officially completely unsupported. All the old-blood developers appear to have moved on to other things, presumably because the 'hard parts' have all been mainlined now. So sourcing the runtime from somewhere else now seems like a useful proposition. But changing more than was really needed to do that does make describing this as a "mess" look like a generous understatement ... Is it really that bad, and if so is it really too late to back away slowly and make this less disruptive to established users? It would be nice to actually have an orderly 'upgrade' path through this rather than an "everything is different now" paradigm shift. It is just a toolchain after all. For a rather old and settled architecture. Ron -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111110210628.gq...@audi.shelbyville.oz
