[opam-devel] On self-upgrade

[Anil Madhavapeddy]

On 25 Jun 2014, at 20:15, Thomas Gazagnaire <thomas at gazagnaire.org> wrote:

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

Yeah, it's worth noting that this did indeed horribly break in the past (the system compiler upgrade from 4.00.1 to 4.01.0 and OPAM from 1.0 to 1.1 didn't work if you did a `brew update` and upgrade both simultaneously).  Upgrading in general is a very tedious, err-prone process that is usually poorly tested, with bugs only biting you a year down the line on release+1 :-)

This might be a little radical, but it's worth considering having a completely separate directory namespace for repo version bumps, and just recompile all the packages on upgrade (it's a very rare situation, after all).

~/.opam/1.1/<...>
~/.opam/1.2/<...>

-anil