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

[Roberto Di Cosmo]

On Sat, Feb 01, 2014 at 02:18:03PM +0100, Anil Madhavapeddy wrote:
> 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, 

Really? I would like to know more about this; please add the factual elements
to #1150

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

Now, that's a tricky issue: with dozens of platforms to support, getting the
opam platform-specific package rolled out in a timely manner, and without
too much skew is definitely far from easy.

> 
> Getting the recursive dependency sorted for a rolling upgrade is a lot of
> work, hard to test, 

Again, I'd like to see more precise arguments about this: I'm surely too
optimistic, but it might just be a matter of adding some specific metadata
for the opam package.

> and of questionable utility (since the original OPAM will be obtained via
> the OS package manager, 

See above

> and the new one will disappear if the
> ~/.opam is destroyed by the user, therefore downgrading their version of OPAM).

Sure, but if I shoot myself in the foot and destroy ~/.opam, that's my proble, right?


> -anil

-- 
Roberto