OPAM 2 interpretation of 'arch:' field is backward incompatible with OPAM 1

[mato]

As discovered by @kit-ty-kate in mirage/ocaml-solo5/pull/36, OPAM 2 appears to have a different interpretation for the arch: field compared to OPAM 1:

• OPAM 2: arch: the host architecture, typically one of "x86_32", "x86_64", "ppc32", "ppc64", "arm32" or "arm64", or the lowercased output of uname -m, or "unknown"
• OPAM 1: arch: the host architecture, as returned by uname -m

In practice, this is causing extra work for packages which require arch-dependent constraints, as the arch value will be different for OPAM 1 and OPAM 2.

Possibly related, it appears that even on the same os and arch (OpenBSD on amd64) the values do diverge: mirage/ocaml-solo5#35 (comment)

I'm not sure what the correct solution is here, but as a first step I'd like to know what the intent behind this change to OPAM 2 was, and what the exact semantics for OPAM 2 are?

If at all possible I'd prefer to work towards a solution that does not result in adding more arch constraints to package definitions in order to accomodate OPAM 2.

[dbuenzli]

See #3058

[mato]

@dbuenzli Thanks for that.

I have two questions:

1. What, if anything, should we do to preserve backward compatibility with existing (OPAM 1.x) package definitions?
   A suggestion: Would it make sense for OPAM 2 to accept some of the values currently used in existing packages as aliases, possibly printing a warning along the way? Specifically, arch=amd64 as an alias for arch=x86_64 and arch=aarch64 as an alias for arch=arm64 come to mind.

2. How is a package maintainer (or other contributor) supposed to easily work out what the arch or os values might be on their system without running both OPAM 1 and 2 on it?

[AltGr]

1. for now, unless you want to publish only to the 2.0.0 branch of the repo, you should indeed remain in opam 1.2 format, including the arch variable values. It's actually the job of the opam format upgrader (as called by opam admin upgrade-format, or @camelus) to migrate to the newer format, I'll fix the missing cases.

   Using aliases is not really practical without extremely ad-hoc hacks, since this is using a generic expression mechanism, and the arch variable can only have one value

2. Hmm, not easy; if you are on opam 2 you could use opam config report for opam 2, and uname manually to infer the opam 1 value, but I agree this is not very convenient. Hopefully, it will get easier once we can really make use of the opam 2 format ; and until then, you should indeed only be concerned with the opam 1.2 values if you submit to opam-repository master.

[mato]

@AltGr Just to confirm that I understand correctly: Both of the cases that I mention (mirage/ocaml-solo5#36, mirage/ocaml-solo5#35 (comment)) are due to a bug in the format upgrader? So we should stick with the 1.2 format for those packages and things will keep working?

I presume the format upgrader is also used when installing packages from local pins?

[AltGr]

Underlying issue fixed by #3296. Thanks for reporting!

[mato]

Thanks. I'll wait for a -rc2 build with this fix, then report back once tested.

[mato]

@AltGr I've tested this at least in the OpenBSD cases, and with a build of OPAM 2 from today's master and all seems fine, so am going to close this as fixed.