[opam-devel] How to manage a package manager (Was: Re: [opam] Build clarification (#1149))

[Anil Madhavapeddy]

On 1 Feb 2014, at 14:10, Roberto Di Cosmo <roberto at dicosmo.org> wrote:

> ===>           opam version n+1 is added also to repo version n
> ===>
> ===> Sometimes later: the user of opam n runs an update, sees that a new
> ===>                 version of opam is available, and upgrades it...
>                      he now has the new opam, that updates the references
>                      to the new repository, and keeps following the evolution
>                      of the repository, with no pain
> 
> So, basically, my big feature whish is to see opam *packaged* as an opam
> package. 
> 
> I remember that in the past that was the case, but there were issues
> that forced opam to stop being an opam package. 
> 
> I wonder what these issues were, and whether they can now easily be solved...
> one is the location where the binary opam should be installed: as I said in my
> previous mail, it cannot go under the 4.00/3.12/whatever directories, as it is
> supposed to be the package manager, maybe there are other?

This is a very tricky interaction to get right, and the opportunity cost is
that of focussing on better upstream integration of OPAM itself.

My view is that we should focus on getting the OPAM packages upstreamed more
widely, and (possibly) provide package manager hooks to trigger an OPAM update
along with an OS update.

Getting the recursive dependency sorted for a rolling upgrade is a lot of
work, hard to test, and of questionable utility (since the original OPAM will
be obtained via the OS package manager, and the new one will disappear if the
~/.opam is destroyed by the user, therefore downgrading their version of OPAM).

-anil