[darcs-users] zlib plans

Ganesh Sittampalam ganesh at earth.li
Wed Nov 26 19:01:52 UTC 2008


At Eric's request I chatted to Petr about this, and I now propose the 
following roadmap for migrating darcs over to the Haskell zlib library and 
dropping the direct C bindings completely. Please note that I'm not 
volunteering to do any of this work :-) Much/all of this has been 
discussed or agreed, I'm really just making the sequencing explicit.

(1) ASAP, move the cabal default back to the C zlib, to mitigate the 
current issues people are experiencing with corrupt checksums in .gz files 
produced by old versions of darcs. This might make the situation on 
Windows a bit worse, as the cabal build will become broken by default, but 
this just sets our plans for "good support" for Windows back a bit, 
whereas not doing it means a lot of trouble on all platforms.

(2) I understand that Haskell zlib 0.5.1 is planned, with an interface 
that will return the "broken" decompressed data at the same time as 
reporting CRC errors. When this appears:
  (a) Make darcs use this interface to accept but warn about broken .gz
      files. We wouldn't maintain support for zlib 0.5.0 - as with the
      previous zlib transition, too much pain for too little gain.
  (b) [probably needs to be simultaneous with (a)] Make darcs repair, or an
      external program bundled with darcs, fix the corrupt checksums.
  (c) [optional] At some point switch the handling of broken .gz files from
      "accept but warn" to "reject". Obviously in both cases the
      warning/error would be clear about how to fix the problem.

(3) Switch the default for everything to the Haskell zlib

(4) Drop the C zlib

(1) and (2) should happen as soon as possible. The precise timing of (3) 
and (4) is a matter of judgement; IMO we should have confidence at each 
step that we won't regret it, and this may mean waiting a few months each 
time; others I think are more keen to dump cruft as quickly as possible.

BTW I haven't heard any suggestion that it's worth keeping the C zlib 
long term. I'm not aware of anything it can do that the Haskell zlib 
can't, and there's just no point in maintaining this inside darcs. If you 
disagree please speak up!



More information about the darcs-users mailing list