Jason Bacon <jtocino%gmx.com@localhost> writes:
> Based on my experience, though, MPI packages could work well in pkgsrc,
> as long as each implementation is isolated, e.g. under
> ${PREFIX}/openmpi/version, ${PREFIX}/mpich/version, etc.
>
> Dependent packages should probably be installed under the same prefix.
> This will be necessary for some dependents like fftw, for which it may
> be necessary to install both mpich and openmpi builds.
This is a fair bit of work, and it's not clear to me:
- if this is a proposal on the table to actually do this in pkgsrc
- if you are intending to do it
I think it's a "we could do this" and "but I'm not".
> I've heard arguments that conflicts between MPI packages and their
> dependents are OK, but that won't fly on an HPC cluster where many
> different users are running different software. Maintaining entirely
> separate pkgsrc trees for each MPI implementation would cost man-hours
> in a field where there's an extreme talent shortage.
I guess on one hand there is making all the mpi packages namespaced, and
then making everything that depends on mpi also namespaced, and somehow
bin things hooked in via alternatives, and on the other somebody kicking
off N builds of pkgsrc. I think it's hard to judge but I'm not doing
either :-)
> wip/openmpi is more or less functional and installs 4.0.0. It shouldn't
> be hard to update it to 4.1.4.
[summarizing things I said offlist for tech-pkg]
I see wip/openmpi is now at 4.1.4, thanks, and I'm trying to test and
resolve a few PLIST issues.
I see that wip/openmpi is namespaced, but that won't do the same for
anything that uses it (and we haven't come to consensus on that, or
against it). Are you wanting to update parallel/openmpi from wip? If
so, do you see the namespace code being activated or disabled? If not,
do you plan to have multiple versions of openmpi in pkgsrc?
(I really don't have strong opinions here, other than it's good to
discuss.)
Attachment:
signature.asc
Description: PGP signature