IMHO, you can also consider /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. In opam2debian (https://github.com/gildor478/opam2debian a utility to precompiled a set of opam packages into a .deb archive), I install the precompiled binaries in /opt/opam2debian.
Although /usr/local is fine as well. I think Daniel idea to install in /usr/local/$NAME is very good. Regards Sylvain Le Thu Dec 11 2014 at 2:03:57 AM, Louis Gesbert <[email protected]> a écrit : > OPAMROOT has a few drawbacks: > * 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 ;)) > * it contains a lot of files you don't actually want in /usr/local (repo > caches, all switches, etc.) > * even a single switch contains a few extra files we may not want in > /usr/local (list of installed packages, pinned packages overlays, etc.) > > 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 > ``` > for dir in sbin bin doc etc lib man share; do > mv /shared/opam/system/$dir/* /usr/local/$dir > rmdir /shared/opam/system/$dir > ln -s /usr/local/$dir /shared/opam/system/$dir > done > ``` > > Which is kind of what Daniel suggested for `opam link`, if I understood > him correctly. > The relocation issue may cause some programs to look back to /shared, but > that shouldn't be a problem. > > Cheers, > Louis > > > - Anil Madhavapeddy, 10/12/2014 23:18 - > > Thanks for the great writeup Simon! > > > > I do wonder why Thomas thinks that OPAMROOT is a bad solution though. It > > seems quite clean to me -- you can have an OPAM installation pointing to > > (e.g.) /usr/local/opam and either add that your global PATH or symlink > binaries > > into /usr/local/bin. > > > > This could be scripted up with a fairly trivial shell script (caveat: > that I > > haven't actually written). > > > > -anil > > > > > On 10 Dec 2014, at 23:12, Thomas Gazagnaire <[email protected]> > wrote: > > > > > > A (bad) solution is to set change OPAMROOT to an appropriate location. > > > > > > Thanks for the write-up, this is very helpful to understand the > use-cases. I've created https://github.com/ocaml/opam/issues/1895 to > track that. > > > > > > Best, > > > Thomas > > > > > > > > >> On 10 Dec 2014, at 13:16, Simon Cruanes <[email protected]> > wrote: > > >> > > >> Hello, > > >> > > >> Is there a blessed way to install packages system-wide using Opam? I > > >> suspect there isn't, so I attached a document [1] that describes my > > >> use-cases and what I'm thinking of (of course I know you opam > > >> developers are busy). > > >> > > >> Thanks! > > >> > > >> Best, > > >> > > > > > > _______________________________________________ > > > opam-devel mailing list > > > [email protected] > > > http://lists.ocaml.org/listinfo/opam-devel > > > > > > > _______________________________________________ > > opam-devel mailing list > > [email protected] > > http://lists.ocaml.org/listinfo/opam-devel > _______________________________________________ > opam-devel mailing list > [email protected] > http://lists.ocaml.org/listinfo/opam-devel >
_______________________________________________ opam-devel mailing list [email protected] http://lists.ocaml.org/listinfo/opam-devel
