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

[Thomas Gazagnaire]

> @samoth : even an approximate brain dump would be very useful here...
> I have opened an issue for this purpose https://github.com/ocaml/opam/issues/1150

Regarding the upgrade issues discussed there.

- you can info OPAM clients which minimal version is needed for a given repo (add `opam-version: "1.1.1"` in `opam-repository/repo` . This information will be read by OPAM 1.0 but it will do nothing useful, behaviour which has been fixed by OPAM 1.1.0 to show a nice error message. 

- as we though this was not enough flexible, we instead rely on an other mechanism to ensure forward compatibility: the individual opam files contains an (optional) `opam-version` field which is the minimal version of the client needed to read them. From OPAM 1.1.0, the client starts to skip these instead of failing (as it was the case in 1.0.0). Also, OPAM 1.1.0 will skip the fields it doesn't know about (you can still tell it to fail on error using --strict).

- to help upgrading, we also added a `redirect` field in `opam-repository/repo`, which can be enabled depending on the version of the OPAM client reading it. This will let us having different repo for different versions. The goal was to keep the most up-to-date description compatible with the latest version, and back port automatically new additions to previous repository versions. There is a `--compat-mode-1.0` command-line option which starts to do that, but this is clearly not the most urgent need so this didn't go very far (and won't go very far, unless someone proposes a patch).

- the latest version of OPAM is always available at the same url: https://github.com/ocaml/opam/archive/latest.tar.gz

- why OPAM is not packaged in OPAM ? See for instance https://github.com/ocaml/opam/issues/373 The issue comes up when you mix your system OPAM and the one installed by OPAM itself: for instance, when you initialise your environment (using "eval `opam config env`" in your .bashrc, as some people do). The good solution might be to have a command to install binary globally (`opam install foo --global`) or using some tricks with env variable overrides (see https://github.com/ocaml/opam/pull/1153).

To summarise, I don't see the upgrade between version of OPAM as a real concern from now on (we have just enough machinery needed in OPAM for our needs I think).

Best,
Thomas