[opam-devel] On self-upgrade

Louis Gesbert louis.gesbert at ocamlpro.com
Wed Jun 25 19:07:36 BST 2014


Hi all,


The self-upgrade feature was introduced on March 20 [1], and there has been very little feedback so far, yet I have been told it raises some concerns so let me summarise the (simple) idea behind it and how it's expected to work. Note that it opens the gate for self-upgrades but the feature in itself doesn't trigger any new behaviour. I've more recently been adding version-checks [2] and a companion opam self-upgrade package [3].

* At startup, as soon as possible, OPAM checks if there is an 'opam' exe and 'opam.version' file in OPAMROOT.
* If the version is newer than current, OPAM exec()s it.
* We pass information through the environment to make sure that only happens once.
* You can bypass it with OPAMNOSELFUPGRADE=1 or --no-self-upgrade
* Information about what happens is present in several places to avoid surprises:
  - at the beginning of the debug log
  - in `opam config report`
  - as a warning if the system version is not a release
* This is opt-in: the idea is to provide the opam and opam.version files through an opam package, that the user explicitely installs [3]. The package should explain what happens to the user (eg. via descr and post-messages).
* It can already be tested with `opam pin opam-bin git://github.com/ocaml/opam`. You need a recent version.
* It follows that upgrades may come through the opam-repository, or git if pinned.

I've attempted to make this as fool-proof as possible, and put good grounds first to enable further fixes within the opam package. The worst scenario I can think of is that your opam-self package is removed (failed to build, upgrade interrupted, or whatever reason). We then fallback to the system OPAM, that should still work ; if the repo format changed in the meantime, opam will advertise that it needs a newer version at startup, and you'll need to go through another channel to get it back. Annoying but not a critical failure, and we could mitigate this eg. with a backup advertised in the post_messages.

This feature has long been asked for [4] and I do think it is a useful one, if done right: it makes deployment of new versions faster and easier, helps people try out bleeding-edge versions if they want to, and generally makes upgrading easier for the user. Besides, people are expecting it.

Cheers,
Louis


PS: I'm currently going through the bug-tracker and preparing a 1.2.0-beta



[1] https://github.com/ocaml/opam/pull/1257
[2] https://github.com/ocaml/opam/pull/1440
[3] https://github.com/ocaml/opam/pull/1467
[4] https://github.com/ocaml/opam/issues/528

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/opam-devel/attachments/20140625/042bb1f5/attachment.html>


More information about the opam-devel mailing list