Detection maybe makes a little more sense now:

The seeding package is pulled in iff any package needs (or is) nocrypto.

The seeding library and the starting trigger are pulled in iff any library needs (or is) nocrypto.

I apologise for simply deleting tls+conduit, wasn't sure what to do with it. In general, anything that depends on tls should just work now, so it should be a breeze to re-add.

this makes sense, these will be replaced by a proper HTTPs combinator later.

Regarding the patch: the only point which is not totally clear by reading the patch is when the call to ocamlfind is done. To be valid it needs to be done after the opam packages are installed, as ocamlfind query -r <xxx> will return stuff about installed packages. [An other option is to ask opam instead but that will be slower (as you need to call the solver) and less precise so the current approach is better]

I'll try to play with the patches tomorrow.

First the presence of a package is detected through configure_opam, which calls packages and this is remembered. Then configure_makefile sees the same answer for packages, and calls libraries.

So I think you are right:

On a clean installation, if a user declares conduit via, say, a combinator, it in turn declares tls. As this is not yet installed, nocrypto is not seen by ocamlfind, and mirage-entropy-xen, its dep for entropy on xen, is not added to the package set. But nocrypto is still pulled in by opam to satisfy tls, and since mirage-xen is pulled in too, opam configures nocrypto to also require mirage-entropy-xen. Depending on whether opam can express that the presence of package A causes package B to require package C, this either installs everything nicely, or aborts because nocrypto now requires mirage-entropy-xen.

If the opam succeeded, the call to libraries correctly detects nocrypto (the lib) as being transitively present, adds the correct entropy lib to the linkage set, and emits the init code.

If there is a way to make opam install mirage-entropy-xen before installing nocrypto if mirage-xen is installed, i.e. if there is a way to conditionally require (as opposed to just conditionally using), we can delete the code around package and rely on that. Is this possible?

Otherwise, yes, this is incorrect and the package detection might have to go via opam. Can we just ask it for immediate deps?

Continuing the discussion of mirleft/ocaml-nocrypto#56 (comment) here to centralise stuff.

while this is not nice and clean, I thought the mirage tool would dependency-inject mirage-entropy-xen if nocrypto is in use (nocrypto needs an optional dependency to mirage-entropy-xen, then it'll be recompiled after installation of mirage-entropy-xen)

I don't really like the double compilation scheme, and this won't work very well with the current mirage tool implementation (could be changed though, but I'll try to minimise build time as much as possible).

I think the simpler and not too hacki-ish solution is to always install mirage-entropy-xen when using the xen mode for now on. And then use the detection scheme introduce in that PR to know if we need to link with the ocamlfind library or not.

The only problem with that scheme is that if the user:

• starts from scratch
• configures with the --no-opam option
• installs the opam package manually

but I think it's fine if it is properly documented and if the mirage tool warns the user that using --no-opam might be a terrible idea and if we hard-code some well-known packages that should bring the linking options (ie. "tls").

I'm fine with that. mirage-entropy-xen is also rather lightweight and thus shouldn't harm too much to have compiled whenever someone chooses mirage on xen...

I think the simpler and not too hacki-ish solution is to always install mirage-entropy-xen when using the xen mode for now on.

Agreed. Some comments in the tool referencing why it's included by default (and possibly referencing this PR) would help us remember this whole discussion.

An other approach is to add a virtual mirage-noxen package which will be in conflict with mirage-xen. And then use it to encode implication in the dependency constraints:

depends: [
...
  ("mirage-noxen" | ("mirage-xen" & "mirage-xen-entropy"))
]

Would be better if it is tracked directly by opam though, pinging @AltGr to comment about the possibility of having ocaml/opam#2074 (comment) in opam 1.2.2 ...

I was also toying with the idea of just unconditionally installing mirage-entropy-xen as a quick fix for now.

This is what the patch now does.

Glad to squash the commits if your prefer that.

Looks good to me. If we want to be extra careful we can also verify that the ocamlfind libraries that we are requiring are correctly installed on the system and if not print a warning about potentially missing initialisation function. Not sure it will happen in practice, but as we are providing the --no-opam option people can start making false assumptions ...

How would you add that? I'm a little reluctant to add early exits to functions that look like they are computing extra deps..

I'd do it at the end of the configuration phase, before emitting the preamble code.

Updated. Can still squash the commits.

Looks good to me. Ready to merge and release when the rest of libraries are ready.

since we will have mirage-no-xen anyways (for gmp-xen dependency in zarith), I'd put a conditional dependency in nocrypto: ("mirage-no-xen" | ("mirage-xen" & "mirage-entropy-xen")).
Than, we can remove the hardcoded dependency on mirage-entropy-xen within the mirage tool (in this PR).

@samoht The rest has been merged and tagged, with a PR waiting in opam-dev. This is the last blocker now.