From: "Sébastien Dailly" <sebastien-ocaml@chimrod.com>
To: Thomas Gazagnaire <thomas@ocamlpro.com>
Cc: <caml-list@inria.fr>
Subject: Re: [Caml-list] Re: ~/.opam design
Date: Thu, 30 May 2013 10:14:47 +0200 [thread overview]
Message-ID: <a3fb8eabc251838bbd71927fe4b26ffa@chimrod.com> (raw)
In-Reply-To: <85FC58B0-BA1E-49C0-9380-802315C81592@ocamlpro.com>
Le 2013-05-30 09:38, Thomas Gazagnaire a écrit :
>
> The subject is not closed at all, and we might move in this direction
> in future releases of OPAM. See for instance [1]
Thanks for pointing the issue. I answerd on the mailing list without
consulting the project site.
>
> The current design has a lot of advantages (the main one being that
> you can remove your ~/.opam if you want restart from scratch) and it
> can be tweaked to have a global installation (see [2,3], even if the
> tweak is not very well documented).
Each application has a good reason for beiing installed directly in the
~ directory. But in a deskop usage (server is different), this finaly
create a big polution in the user directory. The xdg try to define a
general usage for preventing this.
> But yes, for some configurations
> (such as shared NFS homedirs), the current situation is not perfect
> and it would be nice to be able to separate the data from the
> configuration bits.
This is a more general problem : exporting the configuration from one
site to another one, or versionning the opam conf in a production server
is greatly facilitated if the configuration is located in a dedicated
path.
> Luckily, all the paths used by OPAM are defined in
> [4] so they can be changed without too much hassle.
The main advantage I can see with the xdg path is that the
configuration path is declared before installing anything, and can be
configured once for a whole system. This allow to configure differents
workspace just by sourcing a bash file ; as I can do with findlib and
${OCAMLFIND_CONF}
I think you can get as many pros as cons, but today, the xdg path is a
standard in a desktop…
Regards,
--
Sébastien
prev parent reply other threads:[~2013-05-30 8:14 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-29 21:29 Florent Monnier
2013-05-30 7:18 ` Sébastien Dailly
2013-05-30 7:38 ` Thomas Gazagnaire
2013-05-30 8:14 ` Sébastien Dailly [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=a3fb8eabc251838bbd71927fe4b26ffa@chimrod.com \
--to=sebastien-ocaml@chimrod.com \
--cc=caml-list@inria.fr \
--cc=thomas@ocamlpro.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox