On Tue, Dec 19, 2006 at 11:35:33AM +0100, Hendrik Sattler wrote: > Hi, > > as of this writing, w32api was updated to version 3.8 and mingw runtime was > update to 3.11.
Hmm... I guess they stopped updating the downloads page at mingw.org. These have only come out in the last few of weeks, so I guess they'll have to wait out the etch freeze before they go into unstable now. Is there anything fixed in them you desperately need? > Additionally, your README.Debian is wrong, caused by the fact that the Debian > minw32-runtime actually includes w32api _and_ mingw-runtime. Only linking > with the latter should actually need the .dll. Do you mean this: The mingwm10.dll file here is required at runtime. You'll need to copy it to wherever your favorite billware runtime dll's are found. It may be a little over-broad, but exactly which part is wrong? The implication is you do not need that file for toolchain operation on the build host. Its only use is on the target at runtime, and is supplied so you can copy it there if you need it. If that's not what it said to you, suggestions for replacement text are welcome. > Maybe splitting that in two packages with different upstream sources and > correct version information would be a better idea! I don't see how this would actually help anything here? The entire mingw toolchain used to be a single monolithic package (and for quite some time that was the preferred way to build it) -- the current structure evolved to provide the minimum number of source packages required to easily bootstrap the compiler to a new arch. The mingw-runtime package provides the arch-all component (headers and precompiled target libs) which means I can manually bootstrap a single arch, then let the autobuilders take care of all of the others. I don't really see how more source packages would be an improvement on any of that... ? > This would also make it easy to spot the currently installed version of > w32api. That is already easy ;-) Check the changelog. For some time now it has provided the record (and notification if you read them when updating your packages) of which upstream releases have been combined and tested. If we were to split these two up, it raises the possibility for many extra permutations that have _not_ been tested. While it makes perfect sense for upstream to distribute them separately (fixes to one are generally independent of the source of the other), we will always use them as a matched pair, so that benefit does not apply. In general, for us, changes to either will mean rebuilding the runtime package and the toolchain... As a general rule, any time you have to rebuild everything, less source packages Work Better. If you have a counter-example that applies in this case, we should consider it though. There are valid exceptions, I just don't see any that need exercise here yet. Best, Ron -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
