Re: tuareg et/ou ocaml-dev ?
Georges Mariano wrote:
> a package ocaml-devel-task (or task-ocaml-devel, I can't remember the usual
> order)
> which leads to the installation of :
> * one package ocaml-utils which may contain things like tuareg, ocamlmake
> etc
> if such things do not really need to build a specific package for them
> (what about tuareg "providing" (Debian parlance) some thing like
> "ocaml-mode" (also in [but not "provided" the standard package ocaml (it
> already contains an emacs mode if I remember well...)
> and
> * auxiliary packages like tuareg (if not in ocaml-utils), ocamlweb (I
> think that ocamlweb *is* a development tool/utility), camlp4(?) and others
> ??
I agree that a meta-package "task-ocaml-devel" would be a good idea.
This package could hence depend on
- ocaml
- ocamlweb
- tools (separate packages, or one ocaml-utils package)
- libraries (separate packages, or one ocaml-libs package)
I don't want to include ocamlweb into ocaml-utils since ocamlweb alone
depends on tetex-* (and suggests hevea).
Before deciding whether utils should be grouped into one package or
be packaged independently we should perhaps first make a list of tools
that we want to have in debian. To start a list (including the
suggestion by Georges):
- ocamlmakefile
- ocamlp4 (is the licence OK ? I have some doubt concerning the advertisment
clauses)
- ocamlwc (is this useful ?)
- ocamldot. The problem is that ocamldot would depend on graphviz (nonfree),
hence it should be packaged separately since it has to go to contrib.
Since for these utils speed is usually not an issue we could byte-compile
them and build archiecture-independent package(s). They will depend on
ocaml anayway.
> PS since Ocaml is a programming language, I think that
> "ocaml-devel-tools" == "ocaml-utils"
> (i.e utilities for a programming language are development tools ...)
Granted. This reminds me of old plans to split ocaml into runtime and
devel. I'll issue a wishlist bug for that against ocaml.
Brent Fulgham sent a proposal concerning libraries to be packaged
some time ago.
However, I don't think that the Provides Mechanism is appropriate here.
This would require a Virtual Package "ocaml-emacs-mode", and this would
only make sense when we had another separate package providing another
emacs mode for ocaml.
-Ralf.
Reply to: