<div dir="ltr"><div><div>This is very helpful.  Thank you for a detailed reply.<br><br>-- <br></div>Best,<br></div>Evgeny ("Zhenya")<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 13, 2018 at 2:26 AM,  <span dir="ltr"><<a href="mailto:louis.gesbert@ocamlpro.com" target="_blank">louis.gesbert@ocamlpro.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On jeudi 12 avril 2018 15:16:48 CEST Evgeny Roubinchtein wrote:<br>
> Dear OCaml platform users and developers,<br>
> <br>
> I am working in an environment where OCaml (but not OPAM) is installed<br>
> system-wide via RPMs, along with a few OCaml libraries.  All of the<br>
> libraries have corresponding OPAM packages.   I would like to create an<br>
> OPAM  switch that is an alias of the "system" switch, but to also inform<br>
> OPAM about the packages already installed system-wide.  Simply creating a<br>
> switch a as an alias of "system" seems to "not notice" any of the libraries<br>
> installed via RPMs.  Do you have any suggestions?<br>
> <br>
> The set of RPMs installed on the system changes at glacial speeds, so<br>
> having a dumb script into which I hard-code some information about the<br>
> packages installed by system-wide RPMs is perfectly acceptable in my case,<br>
> if a more elegant solution does not exist (yet): I just would like to know<br>
> what information I would need to hard-code, and I am hoping that asking<br>
> here can save me a few hours of hunting through the OPAM source code.<br>
> <br>
> In case it matters, this is OPAM 2.0 pre-release.<br>
> <br>
> Thank you in advance!<br>
<br>
</span>Hi<br>
<br>
This is unfortunately not supported at the moment, as it would be quite <br>
difficult in general to map system packages (from all the OSes and ditributions <br>
out there) to opam packages, including version numbers, fixes, etc.<br>
<br>
If you really want to avoid recompilations, you could try a few workarounds, <br>
though:<br>
<br>
- find the corresponding opam packages and their versions, pin them (with `-n`) <br>
and pretend to install them with `--fake`. This will register them as <br>
installed, but without any processing. It is pretty brittle, though, and be <br>
careful that all fake-installed packages really are on the system.<br>
<br>
- or, much cleaner, but also more work, define your own package repository <br>
(it's pretty simple), get the definitions of the packages you are interested in <br>
from the official opam-repository, and remove their `url` definitions, as well as <br>
build, install and remove instructions to make them dummy packages. Then the <br>
clients should use this repository on top on the official repository (`opam repo <br>
add`) to get the dummy packages. Then, on the client side, make sure to use <br>
`opam pin` to remain on the provided versions of the packages.<br>
<br>
There may still be issues with `ocamlfind`, which needs to find the system <br>
packages besides the opam ones (and here, we can't filter between what is <br>
installed opam-wise or not). Using `setenv:` in the concerned packages might <br>
help.<br>
<br>
Overall, I wouldn't recommend it: this requires quite some work, and there is <br>
no guarantee that it will work reliably (package mapping is never 1-1). This <br>
is the reason why the approach taken by opam is to rebuild all packages from <br>
their source, using its own package definitions. We are experimenting with ways <br>
to have binary caches of packages built by opam, though.<br>
<br>
Best,<br>
Louis Gesbert - OCamlPro<br>
______________________________<wbr>_________________<br>
Platform mailing list<br>
<a href="mailto:Platform@lists.ocaml.org">Platform@lists.ocaml.org</a><br>
<a href="http://lists.ocaml.org/listinfo/platform" rel="noreferrer" target="_blank">http://lists.ocaml.org/<wbr>listinfo/platform</a><br>
</blockquote></div><br></div>