<div><br></div><div>IMHO, you can also consider <span style="line-height:1.5">/opt/$NAME because this is a standard place to install 3rd party application (e.g. Google Chrome). This is more a place for precompiled binaries, but I think it should be fine for system level opam as well. </span><span style="line-height:1.5">In opam2debian (<a href="https://github.com/gildor478/opam2debian">https://github.com/gildor478/opam2debian</a> a utility to precompiled a set of opam packages into a .deb archive), I install the precompiled binaries in /opt/opam2debian.</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">Although /usr/local is fine as well. I think Daniel idea to install in /usr/local/$NAME is very good.</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">Regards</span></div><div><span style="line-height:1.5">Sylvain</span></div><div><span style="line-height:1.5"><br></span></div><div><br></div><div><br></div><br><div class="gmail_quote">Le Thu Dec 11 2014 at 2:03:57 AM, Louis Gesbert <<a href="mailto:louis.gesbert@ocamlpro.com">louis.gesbert@ocamlpro.com</a>> a écrit :<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">OPAMROOT has a few drawbacks:<br>
* you want the switch root (eg ~/.opam/system) at /usr/local, not the global opamroot which would lead to /usr/local/system/lib. Unless you call your switch "local" and set OPAMROOT to /usr... (DON'T do that ;))<br>
* it contains a lot of files you don't actually want in /usr/local (repo caches, all switches, etc.)<br>
* even a single switch contains a few extra files we may not want in /usr/local (list of installed packages, pinned packages overlays, etc.)<br>
<br>
On the bright side, all paths are defined cleanly using module OpamPath, and relocating some parts of a switch to an external directory should'nt be too problematic, as Thomas pointed out. Of course in the meantime, you could use OPAMROOT set as e.g. /shared/opam/ and then<br>
```<br>
for dir in sbin bin doc etc lib man share; do<br>
mv /shared/opam/system/$dir/* /usr/local/$dir<br>
rmdir /shared/opam/system/$dir<br>
ln -s /usr/local/$dir /shared/opam/system/$dir<br>
done<br>
```<br>
<br>
Which is kind of what Daniel suggested for `opam link`, if I understood him correctly.<br>
The relocation issue may cause some programs to look back to /shared, but that shouldn't be a problem.<br>
<br>
Cheers,<br>
Louis<br>
<br>
> - Anil Madhavapeddy, 10/12/2014 23:18 -<br>
> Thanks for the great writeup Simon!<br>
><br>
> I do wonder why Thomas thinks that OPAMROOT is a bad solution though. It<br>
> seems quite clean to me -- you can have an OPAM installation pointing to<br>
> (e.g.) /usr/local/opam and either add that your global PATH or symlink binaries<br>
> into /usr/local/bin.<br>
><br>
> This could be scripted up with a fairly trivial shell script (caveat: that I<br>
> haven't actually written).<br>
><br>
> -anil<br>
><br>
> > On 10 Dec 2014, at 23:12, Thomas Gazagnaire <<a href="mailto:thomas@gazagnaire.org" target="_blank">thomas@gazagnaire.org</a>> wrote:<br>
> ><br>
> > A (bad) solution is to set change OPAMROOT to an appropriate location.<br>
> ><br>
> > Thanks for the write-up, this is very helpful to understand the use-cases. I've created <a href="https://github.com/ocaml/opam/issues/1895" target="_blank">https://github.com/ocaml/opam/<u></u>issues/1895</a> to track that.<br>
> ><br>
> > Best,<br>
> > Thomas<br>
> ><br>
> ><br>
> >> On 10 Dec 2014, at 13:16, Simon Cruanes <<a href="mailto:simon.cruanes.2007@m4x.org" target="_blank">simon.cruanes.2007@m4x.org</a>> wrote:<br>
> >><br>
> >> Hello,<br>
> >><br>
> >> Is there a blessed way to install packages system-wide using Opam? I<br>
> >> suspect there isn't, so I attached a document [1] that describes my<br>
> >> use-cases and what I'm thinking of (of course I know you opam<br>
> >> developers are busy).<br>
> >><br>
> >> Thanks!<br>
> >><br>
> >> Best,<br>
> >><br>
> ><br>
> > ______________________________<u></u>_________________<br>
> > opam-devel mailing list<br>
> > <a href="mailto:opam-devel@lists.ocaml.org" target="_blank">opam-devel@lists.ocaml.org</a><br>
> > <a href="http://lists.ocaml.org/listinfo/opam-devel" target="_blank">http://lists.ocaml.org/<u></u>listinfo/opam-devel</a><br>
> ><br>
><br>
> ______________________________<u></u>_________________<br>
> opam-devel mailing list<br>
> <a href="mailto:opam-devel@lists.ocaml.org" target="_blank">opam-devel@lists.ocaml.org</a><br>
> <a href="http://lists.ocaml.org/listinfo/opam-devel" target="_blank">http://lists.ocaml.org/<u></u>listinfo/opam-devel</a><br>
______________________________<u></u>_________________<br>
opam-devel mailing list<br>
<a href="mailto:opam-devel@lists.ocaml.org" target="_blank">opam-devel@lists.ocaml.org</a><br>
<a href="http://lists.ocaml.org/listinfo/opam-devel" target="_blank">http://lists.ocaml.org/<u></u>listinfo/opam-devel</a><br>
</blockquote></div>