[opam-devel] On self-upgrade

[Anil Madhavapeddy]

On 25 Jun 2014, at 19:07, Louis Gesbert <louis.gesbert at ocamlpro.com> wrote:

> 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.
> 

We've had all sorts of problems in Mirage with having the tool (opam package 'mirage') invoke OPAM to satisfy package dependencies, resulting in OPAM trying to recompile Mirage itself (due to a depopt showing up), but then resulting in a failure due to the classic 'text file busy' error when trying to move the old binary out of the way.

Is there an RT test that goes through the above sequence to simulate an upgrade and downgrade?  I really fear that this route will cause us to ignore system/OS packaging, which is really important to keep up-to-date for a package manager.  The self-upgrade route from within OPAM should never be the primary way to obtain the latest version of the package manager.

-anil