On Mon, Jan 21, 2008 at 09:19:38AM +0100, Stefano Zacchiroli wrote: > On Sun, Jan 20, 2008 at 06:53:38PM +0100, Stéphane Glondu wrote: > > If I understand the Debian OCaml Packaging Policy correctly, .cma files > > should be in libxxx-ocaml-dev binary packages. Has this choice been > > taken with dynamic loading in mind? > > No, it has not. The reason being, I would say, in one of the most > annoying language deficiency (or of its marketing, doesn't matter), > namely: discouraging as much as possible dynamic loading at the point > that basically no program does dynamic loading. > > I'm glad that Ocsigen finally raise the issue ... > > > Ocsigen may, and does with its default configuration and in the most > > useful cases, dynamically load nums.cma, sqlite3.cma, and > > cryptokit.cma, the last two being in *-dev packages. However, I think > > this is confusing: is it ok for an executable to depend on *-dev > > packages at runtime? > > Well, the *-dev naming is just a convention, OCaml *-dev package are not > necessarily related to the C *-dev packages mentioned in the legacy > Debian policy so if we want ... we can do that. Sure it would be not a > nice-looking practice, to everyone a -dev suffix will look like as > something for, well, dev-elopers! > > > When OCaml with native dynamic loading is realeased, where so-called > > "plugins" (.cmxs, I am not talking about .cmx files!) should be put? > > libxxx-ocaml or libxxx-ocaml-dev? The second choice would be > > meaningless, since .cmxs are only meant to be dynamically loaded. And > > the first choice would be inconsistent with the current choice for .cma > > files. > > The point you're raising is indeed quite deep. Thinking about it I came > to the conclusion that our current distinction between libxxx-ocaml and > libxxx-ocaml-dev is quite broken. Indeed, what should be part of the one > and what of the other? The following I think are undebatable: > > libxxx-ocaml: > - shared objects for dynamic loading of C stubs > > libxxx-ocaml-dev: > - developer documentation > - *.mli (and *.ml, if really wanted) > - META files and other build tool support files, stub generators, ...
Do we have some statistics about the size of each of these packages ? If the size is not such an impact, we can just drop the -dev version. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
