* Matthew Maurer: > I've forked your repository for the Jane Street collection of > libraries to: http://github.com/maurer/janest and fixed the FTBFS, > exported more of the libraries in the source package, as well as made > some minor description/install file changes to get it to be lintian > clean (with the exception of some hardening issues that can't be fixed > for ocaml packages).
Even though I am not a member of debian-ocaml-maint (or even consider myself an OCaml programmer), I would like to help you very much in your effort. However, after having looked at your git repository, I am left with a few questions. Hwo come that everything released by Jane Street is now bundled into one big source package? This seems to be a decision made by Lifeng Sun when "importing" upstream version 111.21.00. Where was it imported from? -- I haven't seen any upstream tarball that contains that one great bundle. Does this even make sense? Looking at the tarballs available for download at <https://ocaml.janestreet.com/ocaml-core/>, it seems that not every sub-package is released at every version number bump: 111.17.00 contains: async, async_extended, async_extra, async_inotify, async_kernel, async_parallel, async_unix, bignum, core, core_extended, core_kernel, faillib, jenga, ocaml_plugin, patdiff, patience_diff, sexplib, typerep 111.21.00 contains: async_extended, async_extra, async_ssl, async_unix, core, core_kernel, custom_printf, jenga, ocaml_plugin, patdiff, patience_diff. 111.25.00 contains: async, async_extra, async_kernel, async_parallel, async_unix, core, core_extended, core_kernel, custom_printf, jenga, ocaml_plugin, patdiff, patience_diff, sexplib, textutils 111.28.00 contains: async_extended, async_extra, async_find, async_inotify, async_kernel, async_parallel, async_unix, bignum, core, core_extended, core_kernel, jenga, ocaml_plugin, pa_bench, pa_ounit, patdiff, patience_diff, textutils For example, the libasync-ocaml-dev that would be built out of janest_111.21.00-1.1 is probably from the 111.17.00 release -- but we can't be sure without comparing the source code... This looks bad. What will happen to the existing packages (sexplib310, bin-prot, fieldslib, type-conv)? Cheers, -Hilko -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: https://lists.debian.org/[email protected]
