Fix installation of num for system switches #11207
Conversation
✅ All lint checks passed bedf285
✅ Installability check (8198 → 8198) |
|
Pull request amended to use |
|
The Travis error on macOS previously was suspicious - let's see if it fails again with the new patches. |
|
Still failing with ‘cannot find META.in’, as if it is not applying the patch |
|
Hmm - perhaps renaming a file using a patch is not portable. |
|
OK, I did a bit of testing on my own fork in Travis. It would appear that the patch utility in that version of Xcode patches the file, but doesn't rename it. I have no idea whether that's a bug or whether renaming files in a patch is not a portable to do, but I recreated the patches with |
|
Huzzah - full Travis pass (finally!) |
|
I think we should merge but I don't realy understand the docker error in datakit. @avsm is it fine to merge? |
|
The error is totally "normal". It should be fixed in a couple of days (some bugs in opam master). |
If the num library was installed in a system switch where the user had write permissions to the system compiler's lib directory before ocaml#11207 was merged, then *fresh* installations of the ocamlfind package will detect this "system" installation of num and create a META file for it. This in turn will cause the num package installation to fail. Annoyingly, this failure only appears once because opam then executes ocamlfind remove num so a subsequent attempt to install the num package will appear to have worked. This patch displays a comprehensive error message the first time, strongly suggesting that the user manually delete the files which were incorrectly installed previously.
|
FYI, this change broke at least one reverse dependency of num: #11316 |
See also #10857
The fixes to ocamlfind don't address the fact that the package was still attempting to write to the system's lib directory.
I've proposed the addition of a
findlib-installtarget upstream, the patch for which is included in this PR.