Hi Alastair, On Sat, Feb 03, 2024 at 08:11:21AM +0000, Alastair McKinstry wrote: > Since the time transition is going to require an openmpi transition, I > suggest that the mpi-defaults transition happen simultaneously; > ie mpi-defaults to move 32-bit builds to mpich; openmpi 4.1.6-6 with t64 > libs builds against 64-bit libs only. If I'm interpreting your message correctly, I believe these are relatively orthogonal: you can change mpi-defaults whenever you wish, the packages that depend on libopenmpi3 would still need binNMUing to make them depend on libopenmpi3t64 on armhf. If you arrange it so that at the same time mpi-defaults changes, so that any armhf packages build-depending on mpi-default-dev get rebuilt to depend on libmpich12 instead of either libopermpi3 or libopenmpi3t64, that's fine and would save a round of binNMUs of those same packages later; but that is not a transition that is going to require the same degree of tight coordination wrt unstable uploads and testing migration so I don't think we should block the t64 unstable uploads on an mpi-defaults change. (If you upload mpi-defaults to unstable *first* and get the binNMUs done before the t64 transition lands, that's great and just saves us on the number of binNMUs we will need to schedule.) > Note there is a 5.0.1-1 package in experimental for openmpi that is not > ready for primetime; for the t64 transition use 4.1.6 not 5.0.1. Of course. binary NEW changes are being staged in experimental where possible, but we will not be pulling experimental versions into unstable as part of this. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer https://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: PGP signature