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

[Louis Gesbert]

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-
compilation.

I don't otherwise see any big difficulties for implementing this in opam!

Best,
Louis


Le mardi 13 octobre 2015, 01:31:29 Daniel Bünzli a écrit :
> Hello,
> 
> 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:
> 
> https://github.com/ocaml/opam/wiki/opam-multiarch
> 
> 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 [1]). I know there were attempts at the former so it
> would be nice if we could reach consensus on this first.
> 
> Best,
> 
> Daniel
> 
> [1] https://github.com/ocaml/opam/wiki/opam-multiarch#alternative-designs
> 
> 
> 
> 
> 
> _______________________________________________
> opam-devel mailing list
> opam-devel at lists.ocaml.org
> http://lists.ocaml.org/listinfo/opam-devel