[opam-devel] Start of an opam multi-architecture proposal

Thomas Gazagnaire thomas at gazagnaire.org
Tue Oct 13 13:26:26 BST 2015

>> That might mean maybe renaming `build-os` to `os` so that things stays as they are when build-os = host-os = os.  
> This is actually mentioned in the proposal but your thinking is wrong: non prefixed variable must have host semantics — host is the thing you install, e.g. the variable lib should be equal to host-lib.


>> About the automatic installation of packages when adding a new architecture to the switch: I'm not very found of that. I usually misspell my `git remote add` commands and I'm happy to have `git remote set-url` and `git fetch` as separate commands. So maybe in this case, just lazily install the missing packages for the new arch on `opam upgrade` and `opam install`.  
> Well it can simply ask for confirmation. I think we should avoid a discrepancy between what `opam switch arch list` tells you and install reality (see below).
>> So I think that the constraint: "all installed packages should have the same version for all the architectures" is fine, but the constraint "all installed packages should be installed on all architectures" is too strong.  
> I disagree. I want to be able to treat the switch as an entity regardless of architecture so that a `PKG:installed` variable is `true` iff it is installed in all architecture. If you don't do this then you need to be able to introduce architecture specifiers in variables (e.g. PKG:$(ARCH):installed) which I think we should avoid.

I value simplicity as well so if it works well like that I'm fine (especially if opam give meaningful error messages when the invariants are broken). The `arch-specific` trick seems indeed just powerful enough to deal with partial installations.


More information about the opam-devel mailing list