[opam-devel] How to manage a package manager (Was: Re: [opam] Build clarification (#1149))
Roberto Di Cosmo
roberto at dicosmo.org
Sat Feb 1 13:40:20 GMT 2014
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
> 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,
> 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?
More information about the opam-devel