Re: installation with opam install files

[Stéphane Glondu <glondu@debian.org>]

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