Ease "lockfile" usage on Unix by removing host-arch-* and host-system-* from Unix compiler installs #20
Conversation
ocaml-base-compiler and the +options versions only installing a host-arch-* package on Windows to limit damage to inadequate locking mechanisms.
If ocaml-base-compiler and +options aren't installing a host-arch- package, ensure that _dependencies_ at least can never cause an unexpected host-arch- package to be selected. This obviously does not address conflicts.
This won't be breaking Unix locking, because it's the same, but for consistency with making the host-arch-* packages only be installed by Windows for now, do the same for host-system-*
| @@ -14,3 +14,6 @@ license: "CC0-1.0+" | |||
| homepage: "https://opam.ocaml.org" | |||
| bug-reports: "https://github.com/ocaml/opam-repository/issues" | |||
| conflict-class: "ocaml-host-arch" | |||
| # Temporary, while these packages are not being installed by the compilers on | |||
| # non-Windows builds. | |||
| available: os = "win32" | arch = "arm32" | |||
There was a problem hiding this comment.
| available: os = "win32" | arch = "arm32" | |
| available: os = "win32" & arch = "arm32" |
???
Isn't it the prupose of this change that the package only appears on windows setups?
Or do we still want the packages available if they are requested specifically?
There was a problem hiding this comment.
Currently in opam-repository, when you create a 4.13+ switch, you get the appropriate host-arch- package - which is either a specially-determined one for Windows (which does not depend on the arch variable) or, for Unix, you get the package corresponding to the arch global variable. The available constraint here is designed to leave the selection of the host-arch- package to the compiler package when os = "win32" (which is important - for x86_32 and x86_64 that doesn't necessarily correspond with the arch variable) while stopping a user from managing to manually install, say, host-arch-s390x.1 on macOS, just because that's confusing!
In particular, it means that depending on, say, host-arch-arm64 can still be used to indicate that a package requires arm64 support on Unix. What you can't do with this PR anymore is conflict host-arch-arm64 on Unix.
There was a problem hiding this comment.
Oh ok, that makes more sense. Thanks.
The host-arch- and host-system- packages were added as part of the updates to opam-repository to support native Windows. This support is very much required for Windows OCaml, where the choice between mingw-w64 / MSVC (the system) and i686 / x86_64 is a more critical feature than it is on Linux / macOS / etc.
This has caused a problem for slightly broken, but nonetheless useful, uses of
opam lockwhere a lockfile is generated on one system and then applied to another system (e.g. in CI). In particular, this means that a lockfile generated on an x86_64 Linux system can never be installed on macOS arm64 hardware, because host-arch-x86_64 would be included in the lockfile, where an arm64 installation requires host-arch-arm64. Note that even before this change, there are various easy-enough-to-hit instances where using lockfiles this way is completely broken, but the host-arch- packages unintentionally made this limitation more widespread!There are plans to work on a different lockfile mechanism to cater for this properly, but in the meantime this PR backs out the change for Unix systems. That is, Windows still installs the host-arch- and host-system- packages, because they are needed, but Linux, macOS, etc. no longer install a host-arch- package or host-system-other.