Re: ocaml packaging policy ...
On Thu, Feb 07, 2002 at 04:40:51PM +0100, Jérôme Marant wrote:
> 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.
Mmm, not sure i entirelly follow you here ?
> > 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).
Yes, once i finish the lablgl or some other library package, i will include
the debian/rules file for it.
>
> > 5) Ocaml-best-compilers
>
> Wasn't it ocaml-native-compilers ?
No, ocaml-best-compliers is the virtual package that is provided by
ocaml-native-compilers if it exists and ocaml if not.
No package should depend directly on ocaml-native-compilers, unless it wants
to do arch dependant dependencies.
> > 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
Yes, but not (yet) with virtual packages, of which ocaml-best-compielrs is
one. And using the ocaml-native-compilers, which doesn't exist on all arches,
impose you to use arch dependant dependencies, which you wanted to avoid, i
don't think you would like to go this route.
Anyway, simply depend on ocaml with the correct version, and then on the
-best-compiler package without version, and it will sovle this problem.
Anwyway, the -best compiler is either provided by the ocaml package self, or
by ocaml-bnatiove-compilers, which itself depends on the exact same version of
ocaml.
>
> > 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?
No, i did get it from my own experience with packaging ocaml stuff, and the
bug reports i got when uploading ocaml a new version of ocaml which broke
binary compatibility.
> 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.
Well, yes, but better that than having broken package in testing, don't you
think.
I would much prefer that when i upload a new version of ocaml to testing that
breaks binary compatibility, then all older libraries should be removed from
testing, but i don't know if this is possible with the current testing script.
Friendly,
Sven Luther
Reply to: