Hm. Perhaps I need to go through the control file and be a lot more careful about the versioning to make it match (can I set versions on the individual subpackages built?). While I wasn't the first one to throw these all into the same package, after trying to package these separately futilely myself, I am guessing the reasoning is that these packages all have extraordinarily tight build dependencies on each other, and all build more or less exactly the same way. As a result, one of the easiest ways to build is to pull all the different pieces in. Since users primarily install binaries, it doesn't really pose a bigger burden on them, though I suppose it might add to the burden of the buildbots.
I saw notes in the TODO for the debian-ocaml-maint janest-core repo listing exporting more libs as an item, so I assumed that it was acceptable to migrate other librares that had a source dir in this package into being provided by the package. I would like to hear from some of the debian ocaml maintainers before I attempt to split this though, as they've been at this longer than I have and may be able to more cleanly articulate how the multi-source package was intended to work. Thanks, --Matthew Maurer On Sun, Sep 14, 2014 at 1:08 PM, Hilko Bengen <[email protected]> wrote: > * 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 >
