On 21/07/2017 21:49, Hendrik Tews wrote: >> But this adds opam to bdeps, whitch itself bdeps on cmdliner... > > OK, now we have a real cycle in the build dependencies. At the > moment I see the following solutions: > > ignore: prepare and upload the new topkg package with using > opam-installer, introducing a cycle in the build > dependencies
I'm afraid this won't work at the moment. On bytecode architectures, the opam binary package depends on runtime packages of its dependencies [1]. There is no runtime package for cmdliner, but there is for uutf and jsonm (I guess those will start depending on topkg as well). Now, imagine we start a transition from $ABI to $ABI+1. Suddenly, the whole cycle becomes uninstallable on bytecode architectures. > install-script: add an install script to the new topkg package, > the output of opam-installer --script might provide a > starting point. This script will need manual work for > each new upstream release. This could work for packages that ship a static install file. But what happens for packages that generate their install file during the build? All in all, I'm not very seduced by this approach. > perl-installer: write a replacement for opam-installer, for > instance in perl. This is my preference. > Any preferences? Among the proposed choices, my preference goes to the Perl approach. >> By the way, it makes me think that the dependencies automatically filled >> by dh_ocaml are too coarse. If pkg ocaml-depends on Module and provides >> it, there is (probably) no need to depend on libmodule-ocaml. > > I don't understand this. Is there a relation to the dependency > cycle opam -> cmdliner -> topkg -> opam? I meant, if opam didn't depend on runtime packages of its dependencies, then the dependency cycle wouldn't be a problem. But forget about my ramblings... the dependency on the runtime ocaml-base-nox-$ABI would still be needed and causing trouble on transitions... Unless... we compile opam with -custom. I have to think more about it. Cheers, -- Stéphane
