Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

opam lock includes the host-arch and host-system packages #6042

Open
raphael-proust opened this issue Jun 21, 2024 · 4 comments
Open

opam lock includes the host-arch and host-system packages #6042

raphael-proust opened this issue Jun 21, 2024 · 4 comments

Comments

@raphael-proust
Copy link
Contributor

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
Copy link
Member

hannesm commented Jun 21, 2024

@hannesm
Copy link
Member

hannesm commented Aug 7, 2024

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 ocaml/opam-repository#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 #2247 outlines a solution.

facebook-github-bot pushed a commit to facebook/infer that referenced this issue Sep 5, 2024
Summary:
These are architecture-dependent and as such not always satisfiable.

See also ocaml/opam#6042

Reviewed By: geralt-encore

Differential Revision: D62236842

fbshipit-source-id: d985556513d7367a0c0b1db6252104d9325015e0
@pirbo
Copy link

pirbo commented Sep 24, 2024

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
Copy link
Member

dra27 commented Sep 24, 2024

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants