4) Since mingw is becoming so logically separated from gcc, it is possible that
it could become a separate package. So, if "someone" was willing to supply
a gcc-mingw package, it would actually be helpful. I don't think I could
stand the pain of making this optional, so the gcc package would rely on
the gcc-mingw package rather than the other way around. This would allow
updating libgcc.a and libstdc++.a without requiring a new release of gcc.
Hmm. I wonder if I should break libstdc++.a out of the gcc package. Urgh.
Any suckers (cough) want to contribute a separate package?
I believe Chuck was working on a mingw cross environment that resided on
/opt/mingw. You could do similar and setup a wrapper with the ability
to determine (based on the flags) which gcc to use. Dunno how useful
that would be... Also, perhaps gcc2 could remain, but be named gcc2,
etc. ? This way gcc 3.1 is the default, but people could optionally
use gcc 2 if needs be. This is a real tough one, though. It's too bad
that you can't pass a flag to gcc 3.1 to turn on v2 compatibility mode
(like CC="gcc -v2") but I suppose that is too simplistic... One thing
is for sure, it's almost as bad as the major number changes in glibc.