[opam-devel] global installation with opam

Sylvain Le Gall sylvain+ocaml at le-gall.net
Thu Dec 11 10:01:05 GMT 2014


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 <louis.gesbert at ocamlpro.com>
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 <thomas at gazagnaire.org>
> 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 <simon.cruanes.2007 at m4x.org>
> 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
> > > opam-devel at lists.ocaml.org
> > > http://lists.ocaml.org/listinfo/opam-devel
> > >
> >
> > _______________________________________________
> > opam-devel mailing list
> > opam-devel at lists.ocaml.org
> > http://lists.ocaml.org/listinfo/opam-devel
> _______________________________________________
> opam-devel mailing list
> opam-devel at lists.ocaml.org
> http://lists.ocaml.org/listinfo/opam-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/opam-devel/attachments/20141211/3bd07ecb/attachment-0001.html>


More information about the opam-devel mailing list