>> 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.
ok >> 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. Thomas _______________________________________________ opam-devel mailing list [email protected] http://lists.ocaml.org/listinfo/opam-devel
