Bug#1102928: mpich: mpi-defaults autopkgtest regressions on 32-bit

[Simon McVittie]

Control: clone 1102928 -2
Control: retitle 1102928 mpich: mpi-c.pc no longer available, causing mpi-defaults autopkgtest regression
Control: retitle -2 mpich: mpi-fort.pc no longer available, causing mpi-defaults autopkgtest regression

On Wed, 23 Apr 2025 at 10:58:30 +0100, Alastair McKinstry wrote:
>On 23/04/2025 10:47, Simon McVittie wrote:
>>Fixing the C regression by reinstating the first --slave line
>>seems considerably simpler, and might be enough to fix valgrind on
>>32-bit. Should we clone this bug into a C part which can certainly be
>>fixed, and a Fortran part which might need further discussion?
>>
>Yes, lets go with this.

Cloning as requested. Please use #1102928 to represent the C side of
this (which needs fixing relatively soon so that valgrind can migrate),
and the new clone with a higher bug number to represent the Fortran side
(which from what you've said might be wontfix).

Adrian suggested that reinstating these arguments in the call to
update-alternatives:

--slave /usr/lib/i386-linux-gnu/pkgconfig/mpi-c.pc mpi-c.pc-i386-linux-gnu /usr/lib/i386-linux-gnu/pkgconfig/mpich.pc

(presumably with some substitutions in the source code to get the
appropriate multiarch tuple for the relevant architecture) would be
enough to fix what we're now calling #1102928. I haven't verified that
but it seems plausible.

See also #1088919 and #1089694 which involve packaging changes that were
made in 4.2.x in unstable, migrated to testing successfully, but then
were lost when 4.3.x was re-uploaded from experimental into unstable.
Those packaging changes seem like they might be relevant here.

>>I understand your concern about the late stage of the release cycle, but
>>I also notice that mpich 4.3.x was first uploaded to unstable 2 days
>>before the toolchain freeze, which doesn't seem like an ideal time to be
>>dropping functionality that previously existed and may have been 
>>relied on
>>by dependent packages.
>>
>I think that given circumstances 4.3.* is not ready for trixie.

Do you plan to revert the upload of 4.3.x to unstable by uploading a
4.3.0+really4.2.1 version that matches what's in trixie, or is your
intention that 4.3.x will stay in unstable, without migrating, until
after the trixie release?

The problem with having packages in unstable that are not ready for
trixie is that whenever a dependent package is built on the buildds, it will
be built against the dependency in unstable. For example, in this case,
valgrind has a RC bug fix that *is* desired in trixie, but there is no way
to avoid valgrind being compiled against mpich 4.3.x (at least on 32-bit
architectures), so valgrind is subject to any compile-time regression
that exists in 4.3.x - in particular the disappearance of mpi-c.pc.

Depending on implementation details of the MPI ABI, it's possible that
dependent packages like valgrind might also pick up a versioned
dependency on libmpich12 (>= 4.3.0), which would prevent them from
migrating before mpich does. (I don't know whether this is something
that would genuinely happen for this particular package.)

As a result of factors like those, the release team does not like
packages being uploaded to unstable prematurely, and considers it to be
a RC bug for a package to be in unstable for 30+ days without being able
to migrate (#1103419).

     smcv
     (not a release team member, just a DD trying to help make the release happen)