Re: Adding openmpi-bin to mpi-default-dev
On Thu, Aug 09, 2018 at 06:10:26PM +0200, Mattia Rizzolo wrote:
> I think helmut should chime in as well, so I'm Ccing him now.
I think I talked with Alastair about a related topic earlier.
> On Thu, 9 Aug 2018, 5:16 p.m. Alastair McKinstry, <mckinstry@debian.org>
> wrote:
> > In recent releases, openmpi and mpich have been reorganised so that
> > libopenmpi3 / libopenmmpi-dev are multi-arch enabled.
> >
> > They are M-A: same, allowing the cross-building (and use of pkg-config).
> > However, mpicc/ mpifort and friends hence could
> >
> > not fit into this framework, and so they have been moved from
> > libopenmpi-dev to openmpi-bin.
Thank you for that work. I was able to use the with valgrind, see
#902297.
> > Currently libopenmpi-dev depends on openmpi-bin, in order to ensure that
> > mpicc, etc. are present when users expect.
> >
> > This is bad (a M-A: foreign package depending on a non-MA package).
^^^^^^^
same
But the reasoning is sound.
> > So I propose that mpi-defaults-dev depend on openmpi-bin as well as
> > libopenmpi-dev (on relevant archs) and similarly for mpich.
I don't think you win much by moving the dependency one layer up. For
consumers depending on mpi-default-dev, the situation is exactly the
same.
> > Are there any objections / better solutions ?
Well, from a cross building pov (and unless you are interested in cross
building, Multi-Arch on a -dev package doesn't make much sense), we need
downstreams to stop using mpicc and move to pkg-config (in the long
run).
If you ever want a fully multiarch mpi-default-dev, it has to come
without mpicc. The only choice that seems practical to me is splitting
it and moving the choice (multiarch vs mpicc) into consumers.
So we'd have a mpi-default-without-mpicc-dev package and a
mpi-default-with-mpicc-dev package and each consumer package would
depend on either. Those using the latter would not be able to coinstall
it for multiple architectures. Either of them can take the name
mpi-default-dev, but not both. If the former is chosen to carry the
established name, we immediately make 168 (minus the existing pkg-config
users) rc buggy. If the latter is chosen, we'll have a long road of
telling people that no, you shouldn't depend on mpi-default-dev.
And if that all feels totally depressing, then yes you can leave the
libopenmpi-dev -> openmpi-bin dependency for now. We can still convert
packages towards using pkg-config. We can reevaluate once the problem
has become smaller and the world has understood that using compiler
wrappers is annoying for everyone.
The availability of multiarchy .pc files with working alternatives is a
boon. Much work has happened here (and I guess that's mostly due to
Alastair). We can now proceed to work on the consumers.
In any case, I don't believe that pushing the openmpi-bin dependency up
is going to buy us much unless you want to see the usage of
mpi-default-dev decline.
Hope this helps, but I recognize that it might read as "back to square
one".
Helmut
Reply to: