[opam-devel] On self-upgrade

[Thomas Gazagnaire]

Thanks for you message Louis, it's useful to get some insight of you design.

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

Self-upgrade is indeed kind of simple when you have only one channel to get the software you are updating. Louis, do you have any idea in mind on how this will interact with system upgrade (for instance someone doing `brew update` which will install a newer/incompatible version of your self-upgraded package) ?

I fear that this feature will force us to support all kind of tricky upgrade scenario (1.2 -> 1.3 is ok, but what about 1.2 -> 2.0, or 1.2 -> pin -> 1.1 ?). It's easy to limit these kind of scenario when you control the update channels. When you don't it can quickly become a nightmare.

Thomas