Re: Policy, location of .cma files in binary packages, and dynlink...
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
Reply to: