Re: tuareg et/ou ocaml-dev ?
On Sun, Mar 11, 2001 at 07:46:00PM +0100, Ralf Treinen wrote:
> 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)
Yes, this is the rigth place for this, ...
> I don't want to include ocamlweb into ocaml-utils since ocamlweb alone
> depends on tetex-* (and suggests hevea).
the ocaml-utils should only contain all the stuff that is too small to need a
package of it's own, and that is not yet packaged by itself. In particular if
the size of the stuff who is needed for packaging is more than the size of the
thing packaged, it is not worth a sandalone package.
> 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)
Err, is this different from camlp4, which is already a debian package ?
> - 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.
Yes, it would be better to package it dependently, or maybe do a ocaml-contrib
with this kind of things, and which should go into contrib (because of the
non-free dependance).
That said, is graphviz really needed for ocamldot, or only for
vizualization/useage, if not then we could change the depend to a suggest
alone or something such, and keep it in main.
>
> 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.
Again, my opinion was ever that each package should provide both the bytecode
one and the nativcode binary. But then, some don't agree with me on that.
> > 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.
:)))
(BTW, new dpkg packaging tools seems to be more multi-package friendly, will
try again ...
> 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.
look at the diversion mechanism.
And is the tuareg mode installeable alongside the ocaml provided emacs mode ?
What would be nice is to have somewhere a little description of the difference
between both of them, maybe even in the description ofthe package.
It ever annoyed me to have a lot of packages doing the same thing, and no clue
of which one was more apt for which thing, or other kind of objective
comparison.
And saying 'the best version of xxx around' is no help either.
Friendly,
Svne Luther
Reply to: