On Tue, Apr 19, 2005 at 11:12:55AM +0100, Ross Paterson wrote: > Ian Lynagh <[EMAIL PROTECTED]> writes: > > We're not sure the new hugs should go into sarge without matching new > > ghc/nhc98 due to library changes. We also need to check these changes > > don't cause any breakage elsewhere. > > What incompatibilities with GHC 6.2 and nhc98 1.16 have you discovered > that weren't present in 200311? I know of: > > Library changes (also present in GHC 6.4 and nhc98 1.18): > * instance Integral CTime removed (#299568): > avoid fromIntegral on this type. > * Show andFunctor instances added for FiniteMap: > can be worked around using cpp. > * System.IO no longer re-exports System.IO.Error: > need to tweak imports a little. > > Hugs only: > * locale-based encoding of character I/O (#299570): > use binary I/O for binary data. > * locale-based encoding of filenames and environment variables in H98 libs: > a loss when these are binary or in an unknown encoding, > but a gain for users who use their locale's encoding > (and H98 specifies these as String, not [Word8]).
Given you suggest workarounds I'm going to assume this really means "why isn't the new hugs in sarge?" and answer accordingly, but FWIW I don't remember anything not on your lists above. First a bit of context: When I opened this bug we'd just had the announcement from the release team that the infrastructure holding up the release process "will be fully operational in the space of two weeks", along with a request to avoid uploads of new upstream versions of software; this is even more important in things like libraries and compilers as regressions can affect other packages too. We also had concensus that it was better to ship consistent libraries with each of the implementations, so sarge would at least be consistent with itself even if not the state of the art (and given the state of the art is likely to have additional differences over sarge's lifespan, keeping it compatible is an impossible task). We could have tried to get all the new versions in, together with hmake, darcs and probably more packages that either needed patches backported or new versions uploaded to make them coexist with the changes in the implementations. However, at the time, it seemed better not to rush everything in at the last minute, but rather to stick with the well-tested packages we already had. Having a chronic bug slip through and sarge stuck with it for its whole lifetime would be really annoying! Unfortuantely, more than a month on I believe we're still waiting on the infrastructure. I can appreciate that you are frustrated to not have the latest hugs in the upcoming Debian release, but rest assured that I am equally annoyed by the many missed deadlines and seeming inability of Debian to make progress on the release that means that this is still an open issue. The locale based filename thing in hugs is also a concern, though, in my opinion. Currently two packages build-depend on hugs: haskell-utils and cpphs. I think haskell-utils currently only uses filenames containing a-zA-Z0-9./_ so we could wrap that in a script that sets the locale to C (or maybe do that at the start of main?). cpphs currently accepts 8-bit chars in filenames being #included, as does cpp; maybe you will argue that making use of that is foolish, but nevertheless I think I would rather drop the ability to "compile" with hugs in order to keep its behaviour consistent. We'll also have to go over any packages that stay using hugs to make sure they are opening files in binary mode when appropriate etc. (In principle this should be done regardless, but within the systems Debian currently supports it's not been an issue thus far). Finally, it also means that if everything /did/ go into sarge then the implementations would be less consistent with each other. In terms of non-binary-IO this is probably a good thing, as we shouldn't be encouraging people to use readFile etc as if they did binary IO. But for filenames we just have 2 incompatible designs. I think I've said this before, but while I applaud the efforts to put unicode support into Haskell implementations I would have prefered a suitable replacement of the IO libraries to have been designed first so that the problems with unrepresentable filenames would never have come up. Thanks Ian [1] http://lists.debian.org/debian-devel-announce/2005/03/msg00012.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
