[opam-devel] Start of an opam multi-architecture proposal
louis.gesbert at ocamlpro.com
Tue Oct 13 02:54:18 BST 2015
Nice, well-explained proposal!
I'm not very familiar with cross-compilation, and this has the huge merit of
being easy to understand -- hence to handle, I guess.
I have some remarks on the installability checks: recursively trying to solve
the cross-arch package dependencies would be a bad idea, and what you propose
wouldn't scale well to upgrades, removals, etc. -- thankfully, the solver
should be able to do the work for us yet again.
This is like the multi-switch proposal in some way: before calling the solver,
all packages (or just those that have some dependency differences between
archs, maybe), are duplicated for all archs, and put in the same cudf universe
under different names. But then, we can add mutual dependencies between the
instances of a given package on each architecture, and this separately for
each version of the package. This way, we can be sure they will always be
installed together, keeping the desired "one list of packages for all archs".
Cycles are a problem for resolving installation actions, obviously, but they
are not for the solver.
After the solver call, we can merge back the instances of each package in the
returned solution: the package set is guaranteed to be consistent for every
arch, while having a single version of each package across them.
This wouldn't impact the `arch-specific:` field (which _could_ also make the
package unavailable in case none of its specific arches is present on the
switch, to avoid confusion ?).
I also have a question on build order: is it specified across archs ? Should
only `build` always be first ?
Also, we could probably make it so that `xbin` is an alias for `bin` in the
case of the build arch, so that the change is invisible when not doing cross-
I don't otherwise see any big difficulties for implementing this in opam!
Le mardi 13 octobre 2015, 01:31:29 Daniel Bünzli a écrit :
> I started to write down a few ideas for supporting multiple architecture
> (i.e. cross-compilation) in opam. It's far from complete, glosses over many
> details and maybe too simplistic — but I have the feeling that it's better
> to try to keep things simple in that setting.
> I will certainly not be the person who can fill in all the details —
> especially on how to solve and resolve dependencies, I'm sure the solver
> experts have a better idea of what is needed here than what I'm proposing.
> People who are familiar with `apt` multi-architecture support may also be
> in a better position to design this.
> So I just dumped my broken set of ideas on the opam wiki so that people can
> help to improve it and bring it to a full proposal:
> Feedback and discussion about the general approach is better done on this
> list I think. And this should start with whether the support should be
> handled as an inter or intra switch feature; this proposal being the latter
> (for these reasons ). I know there were attempts at the former so it
> would be nice if we could reach consensus on this first.
>  https://github.com/ocaml/opam/wiki/opam-multiarch#alternative-designs
> opam-devel mailing list
> opam-devel at lists.ocaml.org
More information about the opam-devel