[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: new version of ocaml packages ...



hi,

On Wed, Dec 26, 2001 at 07:18:09PM +0100, Sven wrote:
> 
> I think, unless the above is fixed, that we should resort to the solution
> provided by ralf, which consists of separating the ocaml-base files, and have
> the ocaml package depend on it. But then, this could also justify following on

Yes, I'll prefer that :-)

> with the ocaml package split, and separating more stuff out (particluarly
> camlp4 and labltk for now).

I wonder whether this is really worth the trouble. The case with ocaml-base
is different since someone might just want to run bytecode executables
without being interested in development. On the other hand for someone
who wants to do development in ocaml it seems reasonable that he
installs the complete ocaml package.

One possibility, though, if you want to split the package might be to split
off an ocaml-interactive package which contains everything needed for running
an interactive toplevel. Or to split off a package with
ocaml{c,lex,opt}.opt since these are quite large (together 3MB) and many
people don't need them.

> Another problem is that the replaces, conflicts and provides camlp4 apparently
> don't remove the existing camlp4 package, which sounds like another bug in
> dpkg behavior, or some unimplementezd functionality.

Are you sure? ocaml-3.04-2 does not contain "Conflicts: camlp4".

> Now for the libraries, we could go the same way.
> 
> I thus propose this new scheme :
> 
>   o The dlls will go into a library package (libocaml-xxx for example, or simply
>     libxxx ?)
> 
>   o the rest of the stuff will go into a developpment package
>     (libocaml-xxx-dev ?) which will depend on the library package, and
>     conflicts, replaces and provides the old package name (xxx most often).
> 
> What do you think of this scheme, Should we go ahead with it ? 

Seems reasonable to me.

> What about the naming scheme, should we call it libocaml-xxx or libxxx only ?

The perl people seem to use a naming scheme "libxxx-perl" or
"libxxx-yyy-perl" (try apt-cache search perl lib). The perl policy,
however, does not seem to contain a rule.

Maybe we could use "libxxx-ocaml" where xxx is the upstream name.
Besides of being uniform with the perl people this has the advantage
that the more significant part of the name is at the beginning (think of
dpkg -l cutting off the names of packages).

Best wishes to all of you -Ralf.



Reply to: