Transition to OCaml 3.12.0...
Hello,
Now that Squeeze is released, we can actively work on getting OCaml
3.12.0 into Debian... I've updated the coordination wiki page [1]. I've
not yet set up monitoring pages, but we should be able to directly use
Ben's services [2], now. For information, Ben is based on my transition
monitoring tool and has been deployed for use by the Release Team by
Mehdi Dogguy.
[1] http://wiki.debian.org/Teams/OCamlTaskForce/OCamlTransitions
[2] http://release.debian.org/transitions/
All packages not in the table should be safely binNMU-ed. The table
summarizes work that will need to be done manually. Please have a look,
check your packages, and put your name in the slots you want to handle
yourself.
I based this table on data from the unofficial repository that I made
available shortly after the release of OCaml 3.12.0 (on Sat, 24 Jul 2010
14:24:19 +0200). I didn't take into account all new uploads since then
(nor to unstable, nor to experimental). Feel free to update whatever
needs updating. Before packaging a new upstream version of some library,
please be sure that all its reverse-dependencies compile with the new
toolchain (use official packages or packages you compiled yourself with
them and NOT whatever is available in my unofficial repository as they
might be a bit outdated)... or just wait for OCaml 3.12.0 to be in
testing before pushing new versions.
New in OCaml 3.12.0 from Debian's point-of-view:
* All ocaml{objinfo,byteinfo,...} have been merged upstream into a
single tool, ocamlobjinfo. dh-ocaml (as of 1.0.0) has been updated
accordingly.
* The native compiler has been ported to armel. I've activated it in
my test repository, and almost everything works. Still, there remains
some issues (see the wiki page) and native dynlink doesn't work. To
cope with this, I've introduced in dh-ocaml 0.9.4 an additional
variable OCAML_NATDYNLINK and support for "DYN:"-prefixed lines in
*.in files. Most of the time, replacing "OPT:"-prefixed lines
referring to .cmxs by "DYN:" ones suffices. If your application
relies heavily on natdynlink, it's probably simpler to just not
compile the native version.
Currently, there are very few packages that are not ready for this
transition; basically jocaml and packages FTBFS'ing on armel. If nobody
wants to take care of these promptly, I guess we could just drop them
from testing so that they do not block the transition... what is your
opinion on this?
Please feel free to provide feedback to any point mentioned in this mail.
Cheers,
--
Stéphane
Reply to: