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
_______________________________________________
opam-devel mailing list
[email protected]
http://lists.ocaml.org/listinfo/opam-devel
