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

Re: Bug#599215: Homonymous modules that will conflict in META makes dh-ocaml choke.



Hello,

On 05-10-2010, Guillaume Yziquel <guillaume.yziquel@citycable.ch> wrote:
> Package: dh-ocaml
> Version: 1.0.0~6
> Severity: normal
>
>
> I've been working on an OCaml-Python binding. An I'm currently trying to create
> Debian packages for it. As Python may have multiple binaries for different versions
> of the interpreter, from 2.4 to 3.2, I'm trying to generate automatically packages
> libpython2.4-ocaml-dev to libpython3.2-dev.
>
> As it would impossible to load simultaneously two different versions of the python
> interpreter shared library, it seems natural that these different packages conflict
> in META files (not in Debian's control file).
>
> However, there will be, in each of these libpythonX.X-ocaml-dev packages, an
> oCamlPython.cm[xo] binary/bytecode, without the oCamlPython.cmi file. This is to
> be able to load statically the interpreter. Much like the lablgtk.init findlib package.
>
> I would not like to be able to rename the oCamlPython files upstream (although I will
> presumably be forced to). Keep in mind that they cannot be loaded simultaneously because
> of the META file conflict. The problem is that dh-ocaml fails with
>
> dh_ocaml -s 
> E: Error: unit OCamlPython exported in libpython3.2-ocaml-dev v0.90-2 but already exported by libpython-ocaml-dev v0.90-1
>

Without renaming the file, you can add a dummy function in it, that will
modify the signature and allow computation of dependencies. When
dh_ocaml compute it takes into account the module name and the hash
exported/imported.

If you add a dummy function:

let is_v2_7 = true

include Python.Interpreter (struct end)

or 

let is_v3_2 = true

include Python.Interpreter (struct end)

You should modify the signature of the module and solve the dependency
problem (and the error reported above).

Regards,
Sylvain Le Gall


Reply to: