Re: Adding openmpi-bin to mpi-default-dev
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). ^^^ same 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 same. 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 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. Yes. 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". 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. Regards Alastair Helmut -- Alastair McKinstry, , , https://diaspora.sceal.ie/u/amckinstry Misentropy: doubting that the Universe is becoming more disordered.
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, > 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