Re: ocaml packaging policy ...

[Jérôme Marant <jerome.marant@fr.thalesgroup.com>]

On Thu, Feb 07, 2002 at 12:48:24PM +0100, Sven wrote:

Hi,

>   2) Ocaml library packages
> 
>      A package, named xxx, which provides ocaml libraries should be split as
>      follows :

  It would be nice if you could provide a list of file extensions (cmx,
  cmi, etc) that fit to each section. 

>   3) Ocaml program packages
> 
>      Any package providing executables issued from ocaml source should conform
>      the following regulations.
> 
>      - the package will go by the name of the upstream package, without
>        modifications.
> 
>      - the package debian/rules should build the native code executable if
>        supported on the architecture it is built on, and fall back to building
>        the bytecode version if no working native code compiler is available.
>        And exeption to this are the executables who are small or not time
>        critical, which may be built only as bytecode executable. It is the
>        decision of the individual maintainers to choose this, maybe guided by
>        the practic of the upstream author.

  A sample code of a debian/rules files would be appreciated in order
  to show the building of a package with respect to some requirements
  (for instance, native compiling on architectures supporting it, byte
  code compiling otherwise). 

>   5) Ocaml-best-compilers

  Wasn't it ocaml-native-compilers ?

> 
>      Packages for which it is recommended to use the optimized nativecode
>      compilers to build them should depend on the ocaml package and the
>      ocaml-best-compilers package. The ocaml-best-compilers will provide the
>      best compilers available for that architecture, but as it is a virtual
>      package, it cannot (yet) be a versioned dependency. The version
>      dependency should thus be carried by the ocaml dependency.

  The version dependency is possible with ocaml-native-compilers, IIRC

>   6) Ocaml dependencies.
> 
>      The ocaml libraries should always depend on the exact version of ocaml
>      they were build with. This can be achieved for the 3.04 version of ocaml 
>      with the following dependency:
> 
>      Depends: ocaml (>= 3.04), ocaml (<< 3.05)
> 
>      and 
> 
>      Build-Depends: ocaml (>= 3.04), ocaml (<< 3.05)

  Did you get this idea from the Python policy?

  I think this situation is different with Python since
  many interpreters are provided.

  Doing what you are proposing will lead to some
  problems with testing : if you release a new ocaml, say 3.05,
  it won't enter into testing until every package depending on it
  has updated its dependencies w.r.t the new ocaml version.

  Cheers,

-- 
Jérôme Marant