mail failed, sending to address owner

Barak Pearlmutter bap@cs.unm.edu
Mon, 10 Sep 2001 01:15:24 -0600 (MDT)


Henry,

Here is one encouraging tidbit, from Dale Scheetz, the debian
libgmp2/3 maintainer,

  [mlton's] IntInf.c is using some internals, but nothing obvious I
  can spot that ought to break with gmp 3 (though I say that without
  actually trying it).

That is what encouraged me to just try it in spite of your warning.

Here's the gmp2 vs gmp3 word on the debian street, at least as of April:
http://lists.debian.org/debian-devel/2001/debian-devel-200104/msg00874.html

  Libgmp2 is basicly a rotting pile of junk. There is no upstream
  maintainer, and any actual bugs found there are all fixed in the
  new, maintained, libgmp3.

  I'm getting tired of having to drag this lump along every time I
  make a policy driven change to libgmp3. (see current bugs on
  libgmp2)

  I don't know of a single package that requires libgmp2 over libgmp3,
  and the current packaging allows only one -dev package, so the
  transition is seamless to the dependent packages.

  If there is someone out there who just has to have this package, I
  would love it if you would take over the package. Otherwise I'm
  ready to retire this package.

  Can anyone suggest a reason I should NOT remove libgmp2?

As a result, gmp2 is scheduled to be phased out of the next release.

I personally have no opinion.  The bug tracking system
http://bugs.debian.org/libgmp2/ shows only one actual bug in the gmp2
library itself, which as you say hardly seems "rotting".  On the other
hand, if possible it'd be better to just transition and be done with it.