`opam lock` includes the `host-arch` and `host-system` packages

[raphael-proust]

When running opam lock, the host-arch and host-system packages are included in the lock file. I believe they shouldn't.

In my specific case I ended up with host-arch-x86_64 and host-system-other being listed. I removed them by hand from the lockfile so that my colleagues on other arches/systems would still be able to use the lockfile.

[hannesm]

related https://discuss.ocaml.org/t/reproducible-builds-across-different-architectures/14799 //cc @dra27

[hannesm]

Further discussion at https://discuss.ocaml.org/t/dune-lockfiles-are-not-cross-platform-how-should-we-approach-checking-them-into-version-control/14992/19

What introduced this is the PR https://github.com/ocaml/opam-repository/pull/25861

The key rule is that arch- and system- should never be used in opam files because there are packages (such as ocaml-system) which don't use them. These are also packages which may also disappear in the future if opam gains a way to specify configuration options for to packages at installation time.

I'm really puzzled why a workaround was established so late in the release cycle, while adding the required logic to opam before 2.2 would have been a smooth sail. Now the workaround - a matrix of packages - will be hard to remove: due to backwards compatibility - only once 2.2.0 is out of support it will allow removal of these packages.

It may be that https://github.com/ocaml/opam/issues/2247 outlines a solution.

[pirbo]

All the conf-[TRIPLET]-[DEPEXT] packages that are currently introduced as part of making them available on windows are also material that must be excluded from lock files if we want them to stay useful...

[dra27]

Indeed - the additional packages have had an unintended consequence to what were already imprecise/non-portable lock files. There’s work in flight to address that, but just to note that those packages were never intended as a workaround - in terms of the solver, they are the solution (the switch variable part of #2247 makes slightly less sense in opam 2.x than it did in 1.2, which is one of the reasons my implementation towards it in #2930 never made it)

[kit-ty-kate]

This issue has now been mitigated on non-Windows systems with https://github.com/ocaml/opam-repository/pull/27302 but we hope to propose a reimplementation of opam's lock system to produce portable lock files in the future to fix this issue for good