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 | [email protected] http://www.lucas-nussbaum.net/ | | jabber: [email protected] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
