Hi, On Fri, Apr 06, 2012 at 12:09:14AM +0200, David Kalnischkies wrote: > For mingw32-ocaml the reason is: > binutils-mingw-w64-i686 Conflicts on mingw32-binutils > The naming is again to confusing for me now to inspect it deeper now, > but i guess the "transition" from mingw32 to mingw64 is messed up. > Especially as both are still around in wheezy deciding seems hard.
There is no transition from mingw32 to mingw64, the toolchains are different and their output incompatible. mingw32 is still used as a build-dependency for a few packages so it has to be kept around. There are bugs filed (648306, 623400 and 623402 - I see netbeans now build-depends on mingw32 too, I'll have to look into that) but it's obviously too late for wheezy! What surprises me is that apt-get finds the "correct" solution but then discards it: Investigating (3) mingw32-ocaml [ i386 ] < 3.11.2+debian4 -> 3.12.1+debian2 > ( ocaml ) Broken mingw32-ocaml:i386 Depends on mingw-ocaml [ i386 ] < none -> 3.12.1+debian2 > ( ocaml ) Considering mingw-ocaml:i386 0 as a solution to mingw32-ocaml:i386 10000 Re-Instated binutils-mingw-w64-i686:i386 Re-Instated gcc-mingw-w64-i686:i386 Re-Instated binutils-mingw-w64-x86-64:i386 Re-Instated gcc-mingw-w64-x86-64:i386 Re-Instated gcc-mingw-w64:i386 Re-Instated g++-mingw-w64-i686:i386 Re-Instated g++-mingw-w64-x86-64:i386 Re-Instated g++-mingw-w64:i386 Re-Instated mingw-w64:i386 Re-Instated mingw-ocaml:i386 Investigating (3) binutils-mingw-w64-i686 [ i386 ] < none -> 2.22-1+1 > ( devel ) Broken binutils-mingw-w64-i686:i386 Conflicts on mingw32-binutils [ i386 ] < 2.20-0.1 -> 2.20-0.2 > ( devel ) Conflicts//Breaks against version 2.20-0.2 for mingw32-binutils but that is not InstVer, ignoring Considering mingw32-binutils:i386 1 as a solution to binutils-mingw-w64-i686:i386 1 Holding Back binutils-mingw-w64-i686:i386 rather than change mingw32-binutils:i386 On Wed, Jul 04, 2012 at 05:06:03PM +0200, Luk Claes wrote: > Fixing this bug either means getting rid of the conflict in the > binutils-mingw-w64 packages (and probably have replaces with breaks > instead) or having mingw32-ocaml depend on mingw32 instead of mingw-w64 > (through mingw-ocaml). I suppose in the latter case you mean having mingw32-ocaml use mingw32 and mingw-ocaml use mingw-w64... It seems to me the better solution is something like the first, although binutils-mingw-w64 doesn't actually replace mingw32-binutils (it isn't a drop-in replacement). If mingw32 had been removable I could have provided a mingw32-binutils transition package (as is available for gcc-mingw32) but that isn't the case. Re-reading policy section 7 leads me to believe that the correct approach is a Conflicts/Replaces relationship: mingw-w64-binutils-i686 ships some of the same linker scripts as mingw32-binutils, so it conflicts (both packages can't be unpacked simultaneously), and it should be preferred to it, so it replaces (policy 7.6.2). I'll give that a shot and request a freeze exception if it fixes things. Regards, Stephen
signature.asc
Description: Digital signature
