Re: How is mpi-default-dev supposed to work?
On 23/03/10 at 11:56 +0100, Thibaut Paumard wrote:
> Hi,
>
> Thanks for your answer.
>
> Le 23 mars 10 à 11:22, Lucas Nussbaum a écrit :
> >>I think that this currently does not work reliably since mpich2 has
> >>the same priority (40) as openmpi for the alternatives system. If
> >>package A build-depends on mpi-default-dev and is built on a machine
> >>where mpich2-dev has been installed after openmpi-dev, package A
> >>will be built against mpich2, not against openmpi.
> >
> >That's why we are supposed to build in clean chroots ;)
>
> Depends on what you call "clean": only official packages without
> custom configuration, or minimalistic system. Buildds are the former
> version of "clean", not the latter. Packages required by previous
> builds may be present if you don't build-conflict on them. I know
> there is a recurring debate about that, but this is the current
> situation...
Most buildds have been migrated to using schroot with LVM snapshots, so
it is no longer an issue on those buildds.
> >>- my preferred solution: mpi-defaut-dev could provide links like
> >>mpicc.mpi-defaults that would be the commands actually used when
> >>building. They could also be installed as alternatives with a very
> >>high priority, but I think it is safer to directly use the fully
> >>qualified name "mpicc.mpi-default".
> >
> >That requires transitioning all packages: no.
>
> I don't agree : this solution doesn't break existing packages.
>
> If you install mpicc.mpi-default (et al.) as an alternative for
> mpicc, mpicc is still a link, and in the end it points to the
> expected implementation. Existing packages use it and build
> properly. It's just that by providing the explicit
> mpicc.mpi-default, the system is a little more reliable on "dirty"
> build environments, where the mpicc alternative may have been set
> manually.
>
> If you don't install mpicc.mpi-default as an alternative, this
> solution doesn't fix the problem for existing packages, but it
> doesn't hurt them either: they use the same mpicc as they do
> currently.
Sure, but we don't want a solution that only fixes the problem for
packages that are modified. This effectively requires transitioning all
packages to fix the problem everywhere.
> >other solution:
> >- ensure (in mpi-defaults' postinst) that mpicc points to the correct
> > binary.
>
> By using update-alternatives --set? Hmmm... yes, I guess that should
> work. But still not on dirty build environments, so it will be a bit
> more painful for developers to debug on their machine before they
> pdebuild.
Yes, it's probably better to just conflict in mpi-defaults with the
other providers of mpicc.
> >>For the time being, I will try to make my debian/rules use
> >>mpicc.openmpi if it is available and fall back to mpicc, since the
> >>default is openmpi wherever it can be installed. mpicc may be a link
> >>to mpicc.mpich2 instead of mpicc.lam in some circumstances.
> >
> >Please don't. Follow what the other packages are doing.
>
> Finally I don't use mpi-default-dev at all but I build the two
> versions (openmpi and mpich2). This way I don't have to do something
> I know is flawed and I can look at myself in the mirror again :-)
Note that help is usually welcomed. It might be better to invest time to
solve that problem with a distribution-wide solution, rather than just
for your own package.
--
| Lucas Nussbaum
| lucas@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr GPG: 1024D/023B3F4F |
Reply to: