Hello, On 05-10-2010, Guillaume Yziquel <[email protected]> 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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
