Lucas Nussbaum wrote: > We might chose to make ruby1.9.1 the default ruby implementation for > wheezy (instead of ruby1.8). I still hope that all porting issues > affecting ruby1.9.1 will be resolved. > But if it's down to those four choices, what should I do in a couple of > weeks, when the new upstream release will be available? > (1) not upload the next ruby release to unstable until porting issues > are fixed > (2) disable the test suite on architectures where it fails, so that the > package can build and migrate to testing (but it will be completely > broken, which might annoy DSA, e.g because of puppet) > (3) request removal of ruby binaries on architectures where it fails to > build > (4) orphan ruby1.9.1 ;)
What gcc seems to do (though I may be understanding incorrectly) is to allow the default version to vary by architecture. People interested in a given architecture are expected to do some work to allow a modern version to be used, and if that doesn't happen, it's a bad sign and accounted for in the usual ways. Which I guess is closest to (2) or (3), depending on the nature of the test failures. I can understand if there are details involved that make that not work here, though. -- 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/20110829180607.ga9...@elie.gateway.2wire.net
