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

[Anil Madhavapeddy]

On 1 Feb 2014, at 23:31, Daniel Bünzli <daniel.buenzli at erratique.ch> wrote:

> Le samedi, 1 février 2014 à 19:27, Fabrice Le Fessant a écrit :
>> Let's dream a little: in my ideal world, there would be an OPAM
>> _bytecode_ binary in the opam-repository, always the lattest stable
>> version, and able to upgrade whatever version I have of the
>> opam-repository to the lattest version. Everytime I would do "opam
>> update", OPAM would first check that binary, download it if needed and
>> run it instead of itself (using the same trick as done by ocp-build
>> bytecode to be run on any system), upgrading the repo if needed, and
>> then do the update. The update would be almost completely transparent
>> (maybe OPAM would ask the user to authorize the update, since the user
>> has to trust a binary).
> 
> That seems a little bit overkill no ? And I don't like these binaries.  
> 
> Here's what my naivety says. Why not just have the latest version written in a text file you can GET e.g. at http://opam.ocaml.org/latest-version and on `opam update` check that url too. If there's a mismatch between the user's version and the one in http://opam.ocaml.org/latest-version propose to automatically upgrade by downloading the latest tarball in /tmp configure build and install (at the same previous location opam used to be).
> 
> That's actually exactly what I do manually these days, except I get the latest version announce from a mailing list rather than from http://opam.ocaml.org/latest-version.  

We actually have fledgling support for just this, via the `repo` file
in the root of any OPAM remote:

https://github.com/ocaml/opam-repository/blob/master/repo

What we could do is just add a 'latest-opam-version' field to this
repo file, which would be a hint to the OPAM client to prompt the user
that a newer version is available.

Automating this process would be trickier, since it would corrupt the
checksums that package managers usually maintain if it was initially
installed by that source.  Just seeing the notification would be very
useful, however.

Dangat's point about the multiplicity of package managers reminds me
of a chat I had with the Macports developers a year ago about giving
OPAM a hook into Macports where it could add a hook to run `opam update`
when `ports update` is run.  If someone could investigate if that is
possible on modern package managers, that would be interesting...

-anil