On 09/08/2018 18:56, Helmut Grohne wrote:
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.
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).
But the reasoning is sound.
Yes, but could lead to unexpected consequences. e.g. pulling in
libopenmpi3:arm64 to do cross-building can lead to an unwanted and
potentially incorrect openmpi-bin:x86 being installed.
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
They get the same semantics, but without the problem noted above.
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
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
Hope this helps, but I recognize that it might read as "back to square
I agree with promoting pkg-config (and potentially cmake, etc) over
mpicc, etc. ; what I'm looking to do here is a small fix, not
to undo the effort of deprecating mpicc.
Alastair McKinstry, <alast...@sceal.ie>, <mckins...@debian.org>,
Misentropy: doubting that the Universe is becoming more disordered.