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, ...
The above distinction leaves out bytecode objects and native code
objects; we currently ship both in libxxx-ocaml-dev. I find Stéphane
reasoning convincing on the point that bytecode objects should be part
of libxxx-ocaml. In a future where OCaml gains the capabilities of
dynamically loading native code object probably also them should be
moved from libxxx-ocaml-dev to libxxx-ocaml.
At that point it would be an application choice to either build-dep on
libxxx-ocaml-dev package (which in turn will depend on libxxx-ocaml) and
be fine with that, or *also* have a runtime dep on libxxx-ocaml and
dynamically load what it needs.
This leaves open an issue though. What about bytecode programs which
uses OCaml libraries needing *.so stubs but *not* doing any dynamic
loading of OCaml objects? The solution of moving *.cma to libxxx-ocaml
will imply that all such applications will depend on a much bigger
libxxx-ocaml containing stuff that won't be used. Does this justify an
extra split of libxxx-ocaml in two packages: one containing just the
*.so, the other containing bytecode objects? I'm not sure about that.
> Therefore, I think .cma files should be put in libxxx-ocaml binary
> packages instead, or at least this possibility should be allowed and
> explicitly mentioned in the policy.
I'm not sure what the bottom line is. In principle the split you propose
is the correct one, but basically we have just one package which benefit
from it. Is it worth?
On the bright side, your spit will not mess up dependencies since -dev
packages will still need to dep on other -dev packages and on their non
-dev package so we can even think to do the move of *.cma piecewise.
That, of course, unless we decide to split away the *.so ...
Comments?
Cheers.
--
Stefano Zacchiroli -*- PhD in Computer Science ............... now what?
zack@{upsilon.cc,cs.unibo.it,debian.org} -<%>- http://upsilon.cc/zack/
(15:56:48) Zack: e la demo dema ? /\ All one has to do is hit the
(15:57:15) Bac: no, la demo scema \/ right keys at the right time
Attachment:
signature.asc
Description: Digital signature