[opam-devel] OPAM 1.1 backwards-compatibility

[Louis Gesbert]

Hi all,

A note on the continued compatibility of the main package repository with OPAM 1.1, following the github issue at [1]. Sorry for the length; there's a tl;dr at the start of each paragraph.



## Current situation of OPAM 1.1 support

  [TL;DR] it works for existing installations, but newcomers are greeted by lots of scary warnings and
          required to `opam update`.

* The base idea was to redirect OPAM 1.1 clients to a repo at https://opam.ocaml.org/1.1/ , which is automatically rewritten from the main (1.2) repo still hosted at https://opam.ocaml.org/ . This parts works quite well.

* Sadly, a bug in OPAM 1.1 prevents redirection on `opam init`. So OPAM 1.1 will try to load the default repository, in 1.2 format, until you run `opam update` the first time.

* The current consequence of this is frightening screens full of errors at `opam init` with OPAM 1.1, but mostly harmless. This is documented in the FAQ [2], but is likely to turn away new 1.1 users, e.g. on Ubuntu.

* Another OPAM 1.1 bug causes a _fatal_ parsing error on the `!=` comparator in package version constraints. The consequence is that, were we to start using it in the (1.2) repo, OPAM 1.1 will fail to `init` before getting the chance to be redirected, unless you explicitely direct it to the new repo with `opam init https://opam.ocaml.org/1.1`, as documented in the FAQ.

* A completely different issue, the OPAM package in Ubuntu "utopic" has a broken solver interface [3], it'll seem to work at first, until you try to upgrade.



## Where we want to go, and consequences

  [TL;DR] some 1.2 enhancements to the repo are blocked unless we accept to turn the scary warnings
          into a fatal error. Specific init command (workaround) and existing setups would be
          unaffected.

* The `!=` limitation is annoying because it forces ugly workarounds in the current, main repository (detailed reasons in [1])

* It doesn't look like much but it actually blocks widespread usage of the new OPAM 1.2 features (new fields like `dev-repo`, etc.) that go through PR #3143 [1] for some sanitization prerequisites. In short, I could change #3143 not to use `!=` but that would become an issue on the longer term.

* If we accept `!=` in the repo, OPAM 1.1 will _fail_ to initialize rather than output lots of errors that get fixed by `opam update`. Existing installations, or `opam init https://opam.ocaml.org/1.1` will still work without problem.

* At some point we'll want to freeze 1.1 support anyway ; but stopping updates to opam.ocaml.org/1.1 won't solve this specific issue



## Remarks

  [TL;DR] some other solutions possible, but mostly: how important is OPAM 1.1 support at the moment ?

* An unpleasant, but reliable workaround could be to redirect the main repository to opam.ocaml.org/1.2 and serve a compatible repository at opam.ocaml.org/ . This may get misleading for users, and on the website.

* On a plus note, the "scary warnings" do mention upgrading OPAM.

* This raises the main question: how important is OPAM 1.1 support, how many users will encounter these issues, and when can we safely drop it ? I haven't heard many complaints, but the users hit by this aren't the most likely to give feedback (but maybe to turn around).


Sorry for this sad state of affairs, remarks welcome !
Louis

 


[1] https://github.com/ocaml/opam-repository/pull/3143
[2] http://opam.ocaml.org/doc/FAQ.html#Gaspopaminitgivesmescreensfullsoferrorsaboutupgrading
[3] http://opam.ocaml.org/doc/FAQ.html#OPAMfailstryingtoreinstallalreadyinstalledpackagesatfirstupgrade