[opam-devel] How to manage a package manager (Was: Re: [opam] Build clarification (#1149))
louis.gesbert at ocamlpro.com
Mon Feb 3 10:42:16 GMT 2014
As much as I would like the upgrade of the binary OPAM to be easy and smooth (and arriving quickly everywhere), this is really a problem of bootstrapping. The real big issue that I see there, as Daniel mentionned, is that there is a multiplicity of ways in which OPAM may have been installed, which makes upgrading it cleanly in the general case impossible. The solution that has been mentionned most would be to have two OPAMs on the system, a local and a global one -- on this point I tend to agree with Anil that this is very likely to cause more problems than it solves, whether we do it with a specific OPAM package or with a dedicated mechanism.
The only clean solution for that would be to get rid of any global package managers, and provide one single, official, cross-platform way of installing OPAM. Then only could we reliably control its original installation and reliably upgrade it. Upstream packages of OPAM would be replaced by packages containing our OPAM installer.
That would require some additional work, though, and I am not sure that would be our best move.
Last, it may be different for OPAM because it itself is a package manager, but when there is a proper system-wide package management system, I generally dislike having individual updaters get in the way and complicate things, à la MS-Windows.
A note on the repo file: we have room for supporting nice notifications when OPAM has been updated, and the redirection can be done on the older version rather than the new (redirection can be triggered with conditions having the full power of OPAM filters): having an automatically backported mirror for older OPAMs is an option worth considering.
More information about the opam-devel