[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#648306: The mingw* mess in Debian

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.


Reply to: